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

Jan Kratochvil
2011-09-14T09:13:02Z

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