MI Interface - interpretation of value returned by -stack-list-locals (C++)

MI Interface - interpretation of value returned by -stack-list-locals (C++)

[BarrRobot]

The value returned by "-stack-list-locals 1" (inter alia) is of the form:

^done,locals=[{name="variable",value="a quoted string"}....]

i.e. a List of Tuples containing Results. 

When "variable" of the first Result is a 'complex' type - typically an
instantiated class, the quoted string Value of the second appears to be
exactly the same (with allowance for escaped characters) as that produced by
the equivalent console interface (CLI) command and whilst parts of it
conform to the MI output specification, other parts - I am thinking of the
representation of arrays - do not. Is there an intention to present the
entire output of these commands in the defined MI output syntax, and if not,
what is the recommended way to handle this part of the output, i.e. is it
the expectation to present it 'as is' to the user, or is it safe to attempt
to parse out the component parts and their values with rules derived from
the CLI output?

[The thread "[mi] -stack-list-arguments --simple-values" by Vladimir Prus-3
Jun 30, 2009; 10:39am seems vaguely relevant].
-- 
View this message in context: http://old.nabble.com/MI-Interface---interpretation-of-value-returned-by--stack-list-locals-%28C%2B%2B%29-tp31246347p31246347.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Re: MI Interface - interpretation of value returned by -stack-list-locals (C++)

[André Pönitz]

On Saturday 26 March 2011 17:36:23 ext BarrRobot wrote:
> 
> The value returned by "-stack-list-locals 1" (inter alia) is of the form:
> 
> ^done,locals=[{name="variable",value="a quoted string"}....]
> 
> i.e. a List of Tuples containing Results. 
> 
> When "variable" of the first Result is a 'complex' type - typically an
> instantiated class, the quoted string Value of the second appears to be
> exactly the same (with allowance for escaped characters) as that produced by
> the equivalent console interface (CLI) command and whilst parts of it
> conform to the MI output specification, other parts - I am thinking of the
> representation of arrays - do not. Is there an intention to present the
> entire output of these commands in the defined MI output syntax, and if not,
> what is the recommended way to handle this part of the output, i.e. is it
> the expectation to present it 'as is' to the user, or is it safe to attempt
> to parse out the component parts and their values with rules derived from
> the CLI output?

[I am only a user of MI, so that's not an authoritative answer.]

I think the idea is to present the data to your users in a way you (or
even they ;-}) see fit. If that requires extra formatting or "enrichment"
on top of what is provided by default gdb output it's the task of the MI
"consumer" to create this - possibly by additional communication with gdb.

There will be always special wishes regarding formatting or display layout,
and the gdb side cannot be expected to hardcode all of them. The only
scalable solution is providing hooks for user defined functionality, and for
that gdb already provides Python based scripting. 

Andre'

Re: MI Interface - interpretation of value returned by -stack-list-locals (C++)

[Tom Tromey]

>>>>> ">" == BarrRobot  <robert@rwall.plus.com> writes:

>> Is there an intention to present the entire output of these commands
>> in the defined MI output syntax

I haven't heard of any plans in that direction.

>> and if not, what is the recommended way to handle this part of the
>> output, i.e. is it the expectation to present it 'as is' to the user,
>> or is it safe to attempt to parse out the component parts and their
>> values with rules derived from the CLI output?

All I can think of is that you could make a varobj for the arguments you
are interested in displaying in more detail.

Tom

Re: MI Interface - interpretation of value returned by -stack-list-locals (C++)

[BarrRobot]

Thanks. It would have been nice to avoid the round trip of another call (or
many) to do all the necessary varobjs, so it looks as if I shall chicken out
and present it 'as is' for expediency at this stage.
One for the wish-list maybe?


-- 
View this message in context: http://old.nabble.com/MI-Interface---interpretation-of-value-returned-by--stack-list-locals-%28C%2B%2B%29-tp31246347p31268868.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Re: MI Interface - interpretation of value returned by -stack-list-locals (C++)

[BarrRobot]

Thanks. It would have been nice to avoid the round trip of another call (or
many) to do all the necessary varobjs, so it looks as if I shall chicken out
and present it 'as is' for expediency at this stage.
One for the wish-list maybe?


-- 
View this message in context: http://old.nabble.com/MI-Interface---interpretation-of-value-returned-by--stack-list-locals-%28C%2B%2B%29-tp31246347p31268869.html
Sent from the Sourceware - gdb list mailing list archive at Nabble.com.

Re: MI Interface - interpretation of value returned by -stack-list-locals (C++)

[Tom Tromey]

>>>>> ">" == BarrRobot  <robert@rwall.plus.com> writes:

>> Thanks. It would have been nice to avoid the round trip of another call (or
>> many) to do all the necessary varobjs, so it looks as if I shall chicken out
>> and present it 'as is' for expediency at this stage.
>> One for the wish-list maybe?

Please file a feature request in bugzilla.
The more detailed you can be, the better.

Tom

Re: MI Interface - interpretation of value returned by -stack-list-locals (C++)

[Eran Ifrah]

On Tue, Mar 29, 2011 at 4:57 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>> ">" == BarrRobot  <robert@rwall.plus.com> writes:
>
>>> Is there an intention to present the entire output of these commands
>>> in the defined MI output syntax
>
> I haven't heard of any plans in that direction.
>
>>> and if not, what is the recommended way to handle this part of the
>>> output, i.e. is it the expectation to present it 'as is' to the user,
>>> or is it safe to attempt to parse out the component parts and their
>>> values with rules derived from the CLI output?
>
> All I can think of is that you could make a varobj for the arguments you
> are interested in displaying in more detail.

This is how I chose to implement this under codelite IDE, the problem
is that it doubles the calls I need to pass to the GDB process from
the IDE - and when you have a frame with many variable (I am using
-stack-list-locals followed by -stack-list-arguments 2 0 0 to get the
function arguments as well) it starts to show lag.

BTW, I noticed the Mac's GDB creates a varobj per argument on the
stack / function arg (i.e. the output for -stack-list-locals is list
of varobj ID, the attribute name is the varobj unique id)

>
> Tom
>



-- 
Eran Ifrah
Cross platform, open source C++ IDE: http://www.codelite.org

Re: MI Interface - interpretation of value returned by -stack-list-locals (C++)

[Dodji Seketeli]

Hello BarrRobot,

Tom Tromey <tromey@redhat.com> a écrit:

>>>>>> ">" == BarrRobot  <robert@rwall.plus.com> writes:
>
>>> Thanks. It would have been nice to avoid the round trip of another call (or
>>> many) to do all the necessary varobjs, so it looks as if I shall chicken out
>>> and present it 'as is' for expediency at this stage.
>>> One for the wish-list maybe?
>
> Please file a feature request in bugzilla.
> The more detailed you can be, the better.

Just out of curiosity, Have you filled an enhancement request for this
yet?  [A quick search in bugzilla hasn't yield anything for me].  I have
also taken the route of creating one varobj per local variable in my MI
client.  It works great, but at this point I feel like any round trip
that could be saved can actually make a user visible difference :-) So
if you haven't filed anything yet, I'll file one.

Thanks.

-- 
		Dodji

Re: MI Interface - interpretation of value returned by -stack-list-locals (C++)

[Tom Tromey]

Dodji> Just out of curiosity, Have you filled an enhancement request for this
Dodji> yet?

Yes, please file bugs and requests.

Dodji> It works great, but at this point I feel like any round trip that
Dodji> could be saved can actually make a user visible difference :-)

It would be great to have some data on the importance of this.
Another thing for my to-do list I guess... or yours ;-)

Tom