Re: [MI RFC] entryval: MI access to entry values

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

On Wed, 14 Sep 2011 10:49:51 +0200, André Pönitz wrote:
> In that generality I am afraid I disagree. MI has the ability to transfer data
> in a structured way, there's no reason to pass the "@entry" marker in-channel
> in the "name" field, and there's no reason to assume that a frontend would
> want to present the entry value to the user as a "normal" value, just with a 
> fancy name.
> 
> This is certainly an acceptable way to do it, but why should that needlessly
> be steered by gdb?
> 
> From my point of view, something like 
> 
>    ^done,variables=[{name="lost",arg="1",value="<optimized out>",
>         atentry="5"},{name="born",arg="1",value="10"}]

"atentry" looks exactly like my "entry_value" proposed as variant (2) in (and
implemented in a local patch branch):
	[MI RFC] entryval: MI access to entry values
	http://sourceware.org/ml/gdb-patches/2011-09/msg00036.html


> would be more in the "spirit" of MI,

The problem is the "spirit" of MI is not there.  There should be already
instead of:
	{name="lost",arg="1",value="<optimized out>"}
rather:
	{name="lost",arg="1",optimized_out="1"}
and for value retrieval error messages
	../gdb -nx -i=mi gdb.dwarf2/dw2-param-error
	-break-insert f
	-exec-run
	*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x00000000004004b8",func="f",args=[{name="bad",value="<error reading variable: Asked for position 0 of stack, stack only has 0 elements on it.>"},{name="good",value="23"}]},thread-id="1",stopped-threads="all",core="4"
instead of (the current FSF GDB state):
	{name="bad",value="<error reading variable: Asked for position 0 of stack, stack only has 0 elements on it.>"}
there should be rather:
	{name="bad",error="<error reading variable: Asked for position 0 of stack, stack only has 0 elements on it.>"}
(this reproducing testcase is by me but this MI behavior existed there a long
time before)

So exactly in this spirit I chose rather more the front ends simplicity than
hypothetical MI protocol ideals.

But sure I would rather follow the design goals of the MI maintainer.


> Having said that, the proposed output would work, too, and as long as the
> mangling is deterministic, a frontend can certainly undo it without much effort.

There is already the @entry suffix used in input expressions so it cannot be
non-deterministic anyway.  At least for C/C++ @entry is not ambigous, neither
for Fortran, not sure about all the other languages.


Thanks,
Jan