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

[Jan Kratochvil <jan.kratochvil@redhat.com>]

Hi Volodya,

intro:
	[patch 00/12] entryval: Fix x86_64 <optimized out> parameters, virtual tail call frames
	http://sourceware.org/ml/gdb-patches/2011-07/msg00430.html
currently implemented at:
	http://sourceware.org/gdb/wiki/ArcherBranchManagement
	archer-jankratochvil-entryval

asking here how the MI format should look like.


The CLI part prints (in default `set print entry-values default'):
Breakpoint 8, validity (lost=<optimized out>, lost@entry=5, born=10) at gdb.arch/amd64-entry-value.cc:200

(1)
so I am inclined to just produce these MI records (which normal and @entry
variable variants get included depends on `-gdb-set print entry-values' like in
CLI):
print_frame_args:
	*stopped,[...],args=[{name="lost",value="<optimized out>"},{name="lost@entry",value="5"},{name="born",value="10"}],[...]
list_args_or_locals:
	-stack-list-variables --all-values
	^done,variables=[{name="lost",arg="1",value="<optimized out>"},{name="lost@entry",arg="1",value="5"},{name="born",arg="1",value="10"}]

(2)
currently the archer-jankratochvil-entryval branch implements this variant:
*stopped,[...],args=[{name="lost",value="<optimized out>",entry_value="5"},{name="born",value="10"}],[...]
-stack-list-variables --all-values
^done,variables=[{name="lost",arg="1",value="<optimized out>",entry_value="5"},{name="born",arg="1",value="10"}]
with .exp samples in:
	http://sourceware.org/git/gitweb.cgi?p=archer.git;a=blob_plain;f=gdb/testsuite/gdb.mi/mi2-amd64-entry-value.exp;hb=archer-jankratochvil-entryval

(3)
and I have some older implementation saved which produced:
*stopped,[...],args=[{name="lost",value="<optimized out>"},{name="born",value="10"}],args_entry=[{name="lost",value="5"}],[...]
although the list_args_or_locals mode not sure how it should look like.

(4)
?


The paramname@entry variant (1) requires no extra FE (Front End) extensions,
it should also be fully backward compatible.  The paramname@entry variables are
special that one cannot modify them but that is true also for other variables.

For (2) and (3) for FEs with proper parser an additional result should be
ignored correctly.  For FEs with some ugly manual matching I also do not think
it should be a problem as FEs are usually used for -O0 -g code debugging while
entry values are present only in -O2 -g code.  System libraries would be more a
problem although those on many OSes do not have the -g part.

For the FE->GDB part the FE can normally use `paramname@entry' strings instead
of `paramname' in expression strings as shown in [2].
	[2] http://people.redhat.com/jkratoch/eclipse2.png

The (2) case I tested with eclipse-cdt-8.0.0-5.fc16.x86_64 and ignores the
`entry_value' part correctly.  Maybe it could add the `entry value' in details
of the `val' parameter - as shown in the [1] picture (for that case maybe the
(2) format is better but sure FE is able to use any of the MI formats).
	[1] http://people.redhat.com/jkratoch/eclipse1.png


Thanks for advice,
Jan