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

["André Pönitz" <andre.poenitz@nokia.com>]

On Wednesday 14 September 2011 11:12:33 ext Jan Kratochvil wrote:
> 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.  

I was assuming it at least partially was, and when there are two possible
ways to add new stuff, there could be a bias to the one that's more
"in the spirit".

> There should be already instead of:
> 	{name="lost",arg="1",value="<optimized out>"}
> rather:
> 	{name="lost",arg="1",optimized_out="1"}

That's actually what I'd prefer, too. No magic in-channel strings that need
to be recognized and handled/translated separately, but different kinds
of data transferred in different channels.

I actually had already a stanza like that in the previous mail but removed
it before sending, as I did not want to trigger a compatibilty discussion.

> 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",
> time before)
> 
> So exactly in this spirit I chose rather more the front ends simplicity than
> hypothetical MI protocol ideals.

After giving some more thought I guess you and Volodya are indeed right.

Adding new ad-hoc data mangling is probably really the best for all existing 
frontends. For the "we just dump gdb output into a treeview"-kind of FE using 
whatever looks ok on the commandline is fine in the view, and the few others 
have to massage the output anyway. Adding yet another five lines of code to
recognize and modify the new entries is certainly less effort for the respective
maintainers than pondering the spiritual dimension of a protocol first.

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

Absolutely.

Regards,
Andre'