From: Nick Roberts <nickrob@snap.net.nz>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sources.redhat.com
Subject: Re: MI: type prefixes for values
Date: Fri, 17 Feb 2006 11:27:00 -0000 [thread overview]
Message-ID: <17397.45768.869543.842657@kahikatea.snap.net.nz> (raw)
In-Reply-To: <200602171329.34297.ghost@cs.msu.su>
> > > Also, I note that gdb is currently inconsitent even within itself:
> > >
> > > (gdb)
> > > -thread-select 2
> > > ^done,new-thread-id="2",frame={level="0",func="thread",
> > > args=[{name="p",value="0x0"}],..........
> > > (gdb)
> > > -stack-list-arguments 1 0 0
> > > ^done,stack-args=[frame={level="0",
> > > args=[{name="p",value="(void *) 0x0"}]}]
> > >
> > > Note that first output has "0x0" as value of 'p', and the second has
> > > "(void *)0x0".
> >
> > Also, the first one shows the func= part, the second doesn't.
>
> Heh, the second is not supposed to show func= part at all. MI does not have a
> command equivalent to "backtrace". One has to list -stack-list-frames (that
> does include func=) and -stack-list-arguments (that includes only argument).
> BTW, not very convenient.
>
> > Looks
> > like a bug to me: those two should both use the same code.
>
> Should I file a bug?
Looking at the code -thread-select uses common_val_print which calls
val_print, while -stack-list-arguments uses print_variable_value which calls
value_print. -stack-list-arguments shares code with -stack-list-locals which
can print type information anyway, so if a common style is agreed, I would
prefer the former. Perhaps the call to print_variable_value in
list_args_or_locals can just be replaced to a call to common_val_print.
But there are probably many more inconsistencies and missing or redundant
fields. It won't be possible to add all these in a piecemeal fashion without
repeatedly breaking an existing frontend. I think that a branch is needed so
that the collective changes can be merged into mainline in one go. I have
already stated that I want to create a branch for the asynchronous stuff.
Perhaps the changes could go there (I'm still waiting for Emacs 22 to be
released to avoid to much dilution of effort).
--
Nick http://www.inet.net.nz/~nickrob
prev parent reply other threads:[~2006-02-17 11:27 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-17 9:09 Vladimir Prus
2006-02-17 10:22 ` Eli Zaretskii
2006-02-17 10:29 ` Vladimir Prus
2006-02-17 11:26 ` Eli Zaretskii
[not found] ` <200602171450.16858.ghost@cs.msu.su>
2006-02-17 13:49 ` Eli Zaretskii
2006-02-17 13:54 ` Daniel Jacobowitz
2006-02-17 14:08 ` Eli Zaretskii
2006-02-17 13:58 ` Vladimir Prus
2006-02-17 14:11 ` Eli Zaretskii
2006-02-17 14:26 ` Vladimir Prus
2006-02-17 14:36 ` Bob Rossi
2006-02-17 14:43 ` Vladimir Prus
2006-02-17 14:51 ` Bob Rossi
2006-02-17 15:02 ` Vladimir Prus
2006-02-17 19:25 ` Eli Zaretskii
2006-02-17 19:33 ` Daniel Jacobowitz
2006-02-17 19:36 ` Eli Zaretskii
2006-02-17 19:38 ` Daniel Jacobowitz
2006-02-17 19:56 ` Eli Zaretskii
2006-02-17 20:05 ` Bob Rossi
2006-02-17 20:07 ` Eli Zaretskii
2006-02-17 20:17 ` Daniel Jacobowitz
2006-02-17 20:28 ` Eli Zaretskii
2006-02-17 20:33 ` Daniel Jacobowitz
2006-02-17 21:14 ` Jim Ingham
2006-02-18 11:34 ` Eli Zaretskii
2006-02-20 13:47 ` Vladimir Prus
2006-02-20 8:11 ` Vladimir Prus
2006-02-20 19:49 ` Jim Ingham
2006-02-20 20:56 ` Daniel Jacobowitz
2006-02-20 20:57 ` Jim Ingham
2006-02-21 14:15 ` Vladimir Prus
2006-02-21 21:33 ` Jim Ingham
2006-04-06 13:33 ` Vladimir Prus
2006-04-06 13:45 ` Daniel Jacobowitz
2006-04-06 14:05 ` Vladimir Prus
2006-04-06 14:31 ` Daniel Jacobowitz
2006-04-06 15:05 ` Vladimir Prus
2006-04-06 15:32 ` Daniel Jacobowitz
2006-04-06 18:53 ` Jim Ingham
2006-04-06 16:49 ` Jim Ingham
2006-04-06 16:49 ` Daniel Jacobowitz
2006-04-06 16:52 ` Jim Ingham
2006-04-06 18:58 ` Jim Ingham
2006-04-07 8:13 ` Vladimir Prus
2006-04-07 20:08 ` Jim Ingham
2006-04-12 15:38 ` Vladimir Prus
2006-04-12 19:41 ` Jim Ingham
2006-04-13 16:15 ` Vladimir Prus
2006-02-17 21:19 ` Daniel Jacobowitz
2006-02-17 20:20 ` Bob Rossi
2006-02-17 20:47 ` Daniel Jacobowitz
2006-02-17 19:44 ` Bob Rossi
2006-02-17 19:59 ` Eli Zaretskii
2006-02-20 7:28 ` Vladimir Prus
2006-02-20 23:37 ` Eli Zaretskii
2006-02-21 4:13 ` Daniel Jacobowitz
2006-02-21 14:15 ` Vladimir Prus
2006-02-21 20:41 ` Daniel Jacobowitz
2006-02-20 13:48 ` Vladimir Prus
2006-02-17 11:27 ` Nick Roberts [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=17397.45768.869543.842657@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=eliz@gnu.org \
--cc=gdb@sources.redhat.com \
--cc=ghost@cs.msu.su \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox