This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wednesday 14 September 2011 09:17:42 ext Vladimir Prus wrote:
> On Tuesday, September 13, 2011 23:54:23 Jan Kratochvil wrote:
> > On Fri, 02 Sep 2011 19:07:45 +0200, Jan Kratochvil wrote:
> > > (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"}]
> > 
> > FYI chosen this variant in:
> > 	[patch 07/12+doc] entryval#2: Display @entry parameters
> > 	http://sourceware.org/ml/gdb-patches/2011-09/msg00229.html
> 
> Sorry for not responding earlier. This approach certianly looks best for existing frontneds.

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"}]

would be more in the "spirit" of MI, leaving the question of whether this
should be presented as one entry, as two, with mangled names or without,
with some attempt at localizing the "entry" string or without to the frontend.

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.

Andre'


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]