Re: [RFC 06/12] entryval: Display @entry parameters in bt full

[Jan Kratochvil <jan.kratochvil@redhat.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