This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC 06/12] entryval: Display @entry parameters in bt full
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Wed, 3 Aug 2011 21:42:52 +0200
- Subject: Re: [RFC 06/12] entryval: Display @entry parameters in bt full
- References: <20110718201852.GG30496@host1.jankratochvil.net> <CAN9gPaFFbEXH373MfCsS_LQga65X4VT9T57KnFgXOxpmmGih4g@mail.gmail.com>
On Mon, 18 Jul 2011 23:01:44 +0200, Daniel Jacobowitz wrote:
> * It is really frustrating when GDB knows the value of something, but
> I can't access it as a variable. That means I can't explore it as a
> typed value without having to copy it, paste it, and add a cast to the
> right pointer type. There should be a way to get these values back.
This was addressed by:
[RFC 11/12] entryval: "@entry" in input expressions
> * Any awesomely useful feature like this one should consider MI access
> from the start. How would you want to portray this data in an IDE?
> How would you communicate it through MI to the IDE?
Frontend can ask for the paramname@entry symbols for each paramname.
I will include in the next patchset post "args_entry" MI frame list.
I am aware of various further extensions of this patchset but I wanted to get
some first useful part into FSF GDB after a year of off-trunk development.
I have not considered the MI interface would affect the design of this first
part (sure I may be wrong).
> I am not in love with the @entry name, but maybe we can combine it
> with the above... something like "$at_entry(p)" that could be
> evaluated in an expression? Better naming welcome.
There were no other complaints to the `parametername@entry' naming and I find
it personally more user acceptable than `$at_entry(parametername)'.
`parametername@entry' is evaluable in an expression, the patch:
[RFC 11/12] entryval: "@entry" in input expressions
SystemTap is already using `@entry(expression)' syntax but that exists for
general expressions and it is not based on this DWARF extension (it will
quietly stop+continue at the function entry point for it - like GDB trace).
Thanks,
Jan