-stack-list-locals and children

-stack-list-locals and children

[Niko Sams]

Hi,

-stack-list-locals doesn't return an numchild element. How can the IDE
know if a local
is has children?

If there are children, they are listed in value:
^done,locals=[{name="list",value="QList = {[0] = \"hello\"}"}]

Is it a good idea to parse the value with an regular expression to
find out if there are children?

Or is there a better way to get numchild?

Niko

Re: -stack-list-locals and children

[Vladimir Prus]

Niko Sams wrote:

> Hi,
> 
> -stack-list-locals doesn't return an numchild element. How can the IDE
> know if a local
> is has children?
> 
> If there are children, they are listed in value:
> ^done,locals=[{name="list",value="QList = {[0] = \"hello\"}"}]
> 
> Is it a good idea to parse the value with an regular expression to
> find out if there are children?
> 
> Or is there a better way to get numchild?

I think the right approach is a command that creates and returns varobjs
for locals.

- Volodya

Re: -stack-list-locals and children

[Niko Sams]

On Sun, Jun 28, 2009 at 21:31, Vladimir Prus<vladimir@codesourcery.com> wrote:
> Niko Sams wrote:
>
>> Hi,
>>
>> -stack-list-locals doesn't return an numchild element. How can the IDE
>> know if a local
>> is has children?
>>
>> If there are children, they are listed in value:
>> ^done,locals=[{name="list",value="QList = {[0] = \"hello\"}"}]
>>
>> Is it a good idea to parse the value with an regular expression to
>> find out if there are children?
>>
>> Or is there a better way to get numchild?
>
> I think the right approach is a command that creates and returns varobjs
> for locals.
I thought a large number of -var-create commands could be omitted when using
the value we already get.
Basic tests showed me that -var-create is relatively slow for large lists.

Niko

Re: -stack-list-locals and children

[Vladimir Prus]

Niko Sams wrote:

> On Sun, Jun 28, 2009 at 21:31, Vladimir Prus<vladimir@codesourcery.com> wrote:
>> Niko Sams wrote:
>>
>>> Hi,
>>>
>>> -stack-list-locals doesn't return an numchild element. How can the IDE
>>> know if a local
>>> is has children?
>>>
>>> If there are children, they are listed in value:
>>> ^done,locals=[{name="list",value="QList = {[0] = \"hello\"}"}]
>>>
>>> Is it a good idea to parse the value with an regular expression to
>>> find out if there are children?
>>>
>>> Or is there a better way to get numchild?
>>
>> I think the right approach is a command that creates and returns varobjs
>> for locals.
> I thought a large number of -var-create commands could be omitted when using
> the value we already get.
> Basic tests showed me that -var-create is relatively slow for large lists.

How slow and how did you measure this? I would not expect variable objects to
be considerably slower than printing the value in any other way.

- Volodya

Re: -stack-list-locals and children

[Niko Sams]

On Mon, Jun 29, 2009 at 07:25, Vladimir Prus<vladimir@codesourcery.com> wrote:
> Niko Sams wrote:
>
>> On Sun, Jun 28, 2009 at 21:31, Vladimir Prus<vladimir@codesourcery.com> wrote:
>>> Niko Sams wrote:
>>>
>>>> Hi,
>>>>
>>>> -stack-list-locals doesn't return an numchild element. How can the IDE
>>>> know if a local
>>>> is has children?
>>>>
>>>> If there are children, they are listed in value:
>>>> ^done,locals=[{name="list",value="QList = {[0] = \"hello\"}"}]
>>>>
>>>> Is it a good idea to parse the value with an regular expression to
>>>> find out if there are children?
>>>>
>>>> Or is there a better way to get numchild?
>>>
>>> I think the right approach is a command that creates and returns varobjs
>>> for locals.
>> I thought a large number of -var-create commands could be omitted when using
>> the value we already get.
>> Basic tests showed me that -var-create is relatively slow for large lists.
>
> How slow and how did you measure this? I would not expect variable objects to
> be considerably slower than printing the value in any other way.
I measured using -enable-timings. I did -var-create for a QStringList
with 1000 items, took 0.6sec.

Niko

Re: -stack-list-locals and children

[André Pönitz]

On Sunday 28 June 2009 21:03:01 Niko Sams wrote:
> Hi,
> 
> -stack-list-locals doesn't return an numchild element. How can the IDE
> know if a local
> is has children?
> 
> If there are children, they are listed in value:
> ^done,locals=[{name="list",value="QList = {[0] = \"hello\"}"}]
> 
> Is it a good idea to parse the value with an regular expression to
> find out if there are children?

It would be really nice if 'type' and 'numchild' information was directly
included in that "primary" output. The information is available on
the gdb side, so parsing it from the 'value' field does not really look
like a good solution in the long run.

Andre'

Re: -stack-list-locals and children

[Nick Roberts]

 > > -stack-list-locals doesn't return an numchild element. How can the IDE
 > > know if a local
 > > is has children?
 > > 
 > > If there are children, they are listed in value:
 > > ^done,locals=[{name="list",value="QList = {[0] = \"hello\"}"}]
 > > 
 > > Is it a good idea to parse the value with an regular expression to
 > > find out if there are children?
 > 
 > It would be really nice if 'type' and 'numchild' information was directly
 > included in that "primary" output. The information is available on
 > the gdb side, so parsing it from the 'value' field does not really look
 > like a good solution in the long run.

What would you do with this information?

Note that -stack-list-locals --simple-values _does_ give type information and,
if this is presented to the user, he can usually infer the number of children.
In the manual:

     -stack-list-locals --simple-values
     ^done,locals=[{name="A",type="int",value="1"},
       {name="B",type="int",value="2"},{name="C",type="int [3]"}]
     (gdb)                                             ^^^^^^^

C has three children.

Remember that these aren't variable objects but in Emacs, at least, you can
make variable objects from them simply by clicking mouse-2 on them in the
locals buffer.

It can be expensive to make variable objects from all the locals every time
the frame changes but this is what Insight does, and Apple GDB has MI code
to do it.  So maybe Xcode does too.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: -stack-list-locals and children

[Vladimir Prus]

[I assume you did not CC list accidentally, readding it back]

On Monday 29 June 2009 you wrote:

> >> Basic tests showed me that -var-create is relatively slow for large lists.
> >
> > How slow and how did you measure this? I would not expect variable objects to
> > be considerably slower than printing the value in any other way.
> I measured using -enable-timings. I did -var-create for a QStringList
> with 1000 items,
> took 0.6sec.

This is the current problem with GDB -- it will always try to fetch all
children, which has other problems besides performance. In particular,
if you try to get children of an invalid object, gdb might never finish.
Tom is planning to address this issue soon, and we'll be able to have
incremental fetch of varobj children -- much like we have for stack
frames in KDevelop already.

Also, is -stack-list-locals any better here? I'd expect it to either have
exactly the same performance problems, or ignore pretty-printing. If it
is considerably faster while still reporting 1000 children, it's performance
bug somewhere.

- Volodya

Re: -stack-list-locals and children

[André Pönitz]

On Monday 29 June 2009 10:13:28 Nick Roberts wrote:
>  > > -stack-list-locals doesn't return an numchild element. How can the IDE
>  > > know if a local
>  > > is has children?
>  > > 
>  > > If there are children, they are listed in value:
>  > > ^done,locals=[{name="list",value="QList = {[0] = \"hello\"}"}]
>  > > 
>  > > Is it a good idea to parse the value with an regular expression to
>  > > find out if there are children?
>  > 
>  > It would be really nice if 'type' and 'numchild' information was directly
>  > included in that "primary" output. The information is available on
>  > the gdb side, so parsing it from the 'value' field does not really look
>  > like a good solution in the long run.
> 
> What would you do with this information?

Use it in a GUI frontend to determine whether the item should be
expandable or not. 
 
> Note that -stack-list-locals --simple-values _does_ give type information and,
> if this is presented to the user, he can usually infer the number of children.
> In the manual:
> 
>      -stack-list-locals --simple-values
>      ^done,locals=[{name="A",type="int",value="1"},
>        {name="B",type="int",value="2"},{name="C",type="int [3]"}]
>      (gdb)                                             ^^^^^^^
> 
> C has three children.

Sure I can filter out whatever information is implicitly provided in the output,
and ask for more if needed. But as roundtrips through gdb are expensive
time-wise It would be nicer though if all information necessary to build the
top level of the typical "variable view" could be extracted from gdb in one go.
 
> Remember that these aren't variable objects but in Emacs, at least, you can
> make variable objects from them simply by clicking mouse-2 on them in the
> locals buffer.
> 
> It can be expensive to make variable objects from all the locals every time
> the frame changes but this is what Insight does, and Apple GDB has MI code
> to do it.  So maybe Xcode does too.

Apple creates variables automatically and it is not slow.

Andre'

Re: -stack-list-locals and children

[Vladimir Prus]

André Pönitz wrote:

> On Sunday 28 June 2009 21:03:01 Niko Sams wrote:
>> Hi,
>> 
>> -stack-list-locals doesn't return an numchild element. How can the IDE
>> know if a local
>> is has children?
>> 
>> If there are children, they are listed in value:
>> ^done,locals=[{name="list",value="QList = {[0] = \"hello\"}"}]
>> 
>> Is it a good idea to parse the value with an regular expression to
>> find out if there are children?
> 
> It would be really nice if 'type' and 'numchild' information was directly
> included in that "primary" output. The information is available on
> the gdb side, so parsing it from the 'value' field does not really look
> like a good solution in the long run.

As I mention in other email, getting the number of children is in general
impossible. Maybe, "has_children" flag would be more appropriate -- this
is somewhat more likely to be computable.

I am not sure it was you, but there was an IRC discussion about making
-stack-list-locals also print type of things -- can you describe exactly
how you gonna use that information, so that I have a chance to implement
that properly? 

One important question is whether knowing a type of expression, without
knowing its address, is gonna help you very much.

- Volodya

Re: -stack-list-locals and children

[Niko Sams]

On Mon, Jun 29, 2009 at 10:17, Vladimir Prus<vladimir@codesourcery.com> wrote:
> [I assume you did not CC list accidentally, readding it back]
>
> On Monday 29 June 2009 you wrote:
>
>> >> Basic tests showed me that -var-create is relatively slow for large lists.
>> >
>> > How slow and how did you measure this? I would not expect variable objects to
>> > be considerably slower than printing the value in any other way.
>> I measured using -enable-timings. I did -var-create for a QStringList
>> with 1000 items,
>> took 0.6sec.
>
> This is the current problem with GDB -- it will always try to fetch all
> children, which has other problems besides performance. In particular,
> if you try to get children of an invalid object, gdb might never finish.
> Tom is planning to address this issue soon, and we'll be able to have
> incremental fetch of varobj children -- much like we have for stack
> frames in KDevelop already.
ok, I see.
When this is fixed -var-create should be faster?

> Also, is -stack-list-locals any better here? I'd expect it to either have
> exactly the same performance problems, or ignore pretty-printing. If it
> is considerably faster while still reporting 1000 children, it's performance
> bug somewhere.
It's much faster. I get about 100 children in the value followed by ....

Niko

Re: -stack-list-locals and children

[André Pönitz]

On Monday 29 June 2009 10:59:06 Vladimir Prus wrote:
> As I mention in other email, getting the number of children is in general
> impossible. Maybe, "has_children" flag would be more appropriate -- this
> is somewhat more likely to be computable.

And sufficient for that use case. So yes, that would be fine.

> I am not sure it was you, but there was an IRC discussion about making
> -stack-list-locals also print type of things -- can you describe exactly
> how you gonna use that information, so that I have a chance to implement
> that properly? 

One point was always to reduce the number of roundtrips before
being able to display the variable view. I think that's a valid point
also from a KDevelop angle of view.

> One important question is whether knowing a type of expression, without
> knowing its address, is gonna help you very much.

Yes, as the address is not as prominently displayed in the view as the
type having the type quickly even without an address would help.


Andre'

Re: -stack-list-locals and children

[Niko Sams]

On Mon, Jun 29, 2009 at 10:38, André Pönitz<andre.poenitz@nokia.com> wrote:
> On Monday 29 June 2009 10:13:28 Nick Roberts wrote:
>>  > > -stack-list-locals doesn't return an numchild element. How can the IDE
>>  > > know if a local
>>  > > is has children?
>>  > >
>>  > > If there are children, they are listed in value:
>>  > > ^done,locals=[{name="list",value="QList = {[0] = \"hello\"}"}]
>>  > >
>>  > > Is it a good idea to parse the value with an regular expression to
>>  > > find out if there are children?
>>  >
>>  > It would be really nice if 'type' and 'numchild' information was directly
>>  > included in that "primary" output. The information is available on
>>  > the gdb side, so parsing it from the 'value' field does not really look
>>  > like a good solution in the long run.
>>
>> What would you do with this information?
>
> Use it in a GUI frontend to determine whether the item should be
> expandable or not.
>
>> Note that -stack-list-locals --simple-values _does_ give type information and,
>> if this is presented to the user, he can usually infer the number of children.
>> In the manual:
>>
>>      -stack-list-locals --simple-values
>>      ^done,locals=[{name="A",type="int",value="1"},
>>        {name="B",type="int",value="2"},{name="C",type="int [3]"}]
>>      (gdb)                                             ^^^^^^^
>>
>> C has three children.
>
> Sure I can filter out whatever information is implicitly provided in the output,
> and ask for more if needed. But as roundtrips through gdb are expensive
> time-wise It would be nicer though if all information necessary to build the
> top level of the typical "variable view" could be extracted from gdb in one go.
That would be very nice.

Additionally the arguments could show up in locals too - so
-stack-list-arguments can be skipped.

Niko

Re: -stack-list-locals and children

[Niko Sams]

On Mon, Jun 29, 2009 at 10:59, Vladimir Prus<vladimir@codesourcery.com> wrote:
> André Pönitz wrote:
>
>> On Sunday 28 June 2009 21:03:01 Niko Sams wrote:
>>> Hi,
>>>
>>> -stack-list-locals doesn't return an numchild element. How can the IDE
>>> know if a local
>>> is has children?
>>>
>>> If there are children, they are listed in value:
>>> ^done,locals=[{name="list",value="QList = {[0] = \"hello\"}"}]
>>>
>>> Is it a good idea to parse the value with an regular expression to
>>> find out if there are children?
>>
>> It would be really nice if 'type' and 'numchild' information was directly
>> included in that "primary" output. The information is available on
>> the gdb side, so parsing it from the 'value' field does not really look
>> like a good solution in the long run.
>
> As I mention in other email, getting the number of children is in general
> impossible. Maybe, "has_children" flag would be more appropriate -- this
> is somewhat more likely to be computable.
pretty printers could have an additional method to get numchild directly
without iterating over them.
But for a Tree-View has_children would be enough of course.

> I am not sure it was you, but there was an IRC discussion about making
> -stack-list-locals also print type of things -- can you describe exactly
> how you gonna use that information, so that I have a chance to implement
> that properly?
We don't show a type column in KDevelop, but for example QtCreator does.


Niko

Re: -stack-list-locals and children

[Vladimir Prus]

André Pönitz wrote:

> On Monday 29 June 2009 10:59:06 Vladimir Prus wrote:
>> As I mention in other email, getting the number of children is in general
>> impossible. Maybe, "has_children" flag would be more appropriate -- this
>> is somewhat more likely to be computable.
> 
> And sufficient for that use case. So yes, that would be fine.
> 
>> I am not sure it was you, but there was an IRC discussion about making
>> -stack-list-locals also print type of things -- can you describe exactly
>> how you gonna use that information, so that I have a chance to implement
>> that properly?
> 
> One point was always to reduce the number of roundtrips before
> being able to display the variable view. I think that's a valid point
> also from a KDevelop angle of view.

Right, but how variable type is helping? Is it used *just* to populate
the "type" field in variable view? Or is it also involved in QtCreator's
pretty-printing mechanisms somehow?

>> One important question is whether knowing a type of expression, without
>> knowing its address, is gonna help you very much.
> 
> Yes, as the address is not as prominently displayed in the view as the
> type having the type quickly even without an address would help.

But will address help if the object being displayed needs pretty-printing?
Say, QString? I am not actually sure how you do pretty printing, but I'd imagine 
that address should always be needed.

- Volodya

Re: -stack-list-locals and children

[Vladimir Prus]

Niko Sams wrote:

> On Mon, Jun 29, 2009 at 10:17, Vladimir Prus<vladimir@codesourcery.com> wrote:
>> [I assume you did not CC list accidentally, readding it back]
>>
>> On Monday 29 June 2009 you wrote:
>>
>>> >> Basic tests showed me that -var-create is relatively slow for large lists.
>>> >
>>> > How slow and how did you measure this? I would not expect variable objects to
>>> > be considerably slower than printing the value in any other way.
>>> I measured using -enable-timings. I did -var-create for a QStringList
>>> with 1000 items,
>>> took 0.6sec.
>>
>> This is the current problem with GDB -- it will always try to fetch all
>> children, which has other problems besides performance. In particular,
>> if you try to get children of an invalid object, gdb might never finish.
>> Tom is planning to address this issue soon, and we'll be able to have
>> incremental fetch of varobj children -- much like we have for stack
>> frames in KDevelop already.
> ok, I see.
> When this is fixed -var-create should be faster?

I'd imagine there be global changeable default number of children to fetch,
say 10, so yes, it will be faster.

>> Also, is -stack-list-locals any better here? I'd expect it to either have
>> exactly the same performance problems, or ignore pretty-printing. If it
>> is considerably faster while still reporting 1000 children, it's performance
>> bug somewhere.
> It's much faster. I get about 100 children in the value followed by ....

Ah, hmm. Seems like CLI obeys 'set print elements' setting, then. When MI
obeys it's own limit, I expect there to be no difference.

- Volodya

Re: -stack-list-locals and children

[André Pönitz]

On Monday 29 June 2009 11:39:27 Vladimir Prus wrote:
> > One point was always to reduce the number of roundtrips before
> > being able to display the variable view. I think that's a valid point
> > also from a KDevelop angle of view.
> 
> Right, but how variable type is helping? Is it used *just* to populate
> the "type" field in variable view? Or is it also involved in QtCreator's
> pretty-printing mechanisms somehow?

Right. They are also primary information for the current incarnation of
Qt Creator's pretty-printing. 

However I don't want center the argumentation around the needs of 
a specific IDE though if there is a "cross-IDE" reason. And reducing
roundtrip count should be fairly cross-IDE ;-}

> >> One important question is whether knowing a type of expression, without
> >> knowing its address, is gonna help you very much.
> > 
> > Yes, as the address is not as prominently displayed in the view as the
> > type having the type quickly even without an address would help.
> 
> But will address help if the object being displayed needs pretty-printing?
> Say, QString? I am not actually sure how you do pretty printing, but I'd imagine 
> that address should always be needed.

I get the address filled in "for free" by gdb when invoking the pretty printers.
It's conceptionally[1] something like  running "call dumpQString(&astring)"
through gdb when there is a local "QString astring;" in the code.

So I don't have a specific interest in having the address available in the 
first round.However, in general I would not mind if information that's easily 
available  on the gdb side and that takes only a few characters would be 
output. So if you added an address field I'd certainly not complain ;-)

Andre'

[1] In practice it's way more messy as this needs to work with several 
versions of gdb (and other debuggers for that matter)

Re: -stack-list-locals and children

[Nick Roberts]

 > > Also, is -stack-list-locals any better here? I'd expect it to either have
 > > exactly the same performance problems, or ignore pretty-printing. If it
 > > is considerably faster while still reporting 1000 children, it's performance
 > > bug somewhere.
 > It's much faster. I get about 100 children in the value followed by ....

I think the limit is 200 (show print elements) but if elements repeat themselves
(generally 0) an ellipsis is used.

Presumably it's much faster because -stack-list-locals just prints/dumps out the
values while variable objects allow you to edit, change format, expand, list
changed values etc...

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: -stack-list-locals and children

[Pawel Piech]

Nick Roberts wrote:
> Note that -stack-list-locals --simple-values _does_ give type information and,
> if this is presented to the user, he can usually infer the number of children.
> In the manual:
>
>      -stack-list-locals --simple-values
>      ^done,locals=[{name="A",type="int",value="1"},
>        {name="B",type="int",value="2"},{name="C",type="int [3]"}]
>      (gdb)                                             ^^^^^^^
>   

No kidding!  2 more questions then:

- does stack-list-args support the --simple-values option?
- how long has this feature been around?

Thanks,
Pawel

Re: -stack-list-locals and children

[Vladimir Prus]

Pawel Piech wrote:

> Nick Roberts wrote:
>> Note that -stack-list-locals --simple-values _does_ give type information and,
>> if this is presented to the user, he can usually infer the number of children.
>> In the manual:
>>
>>      -stack-list-locals --simple-values
>>      ^done,locals=[{name="A",type="int",value="1"},
>>        {name="B",type="int",value="2"},{name="C",type="int [3]"}]
>>      (gdb)                                             ^^^^^^^
>>   
> 
> No kidding!  2 more questions then:
> 
> - does stack-list-args support the --simple-values option?

Does not seem so. In fact, it does not seem like -stack-list-locals support if
either ;-). Both take an integer parameter though, passing '2' for it should
cause only simple values to be printed.

> - how long has this feature been around?

Which? Printing types? I believe it was around for approximately -1 day.
However, please be advised that parsing types is very bad idea.

- Volodya

Re: -stack-list-locals and children

[Vladimir Prus]

Vladimir Prus wrote:

> Pawel Piech wrote:
> 
>> Nick Roberts wrote:
>>> Note that -stack-list-locals --simple-values _does_ give type information and,
>>> if this is presented to the user, he can usually infer the number of children.
>>> In the manual:
>>>
>>>      -stack-list-locals --simple-values
>>>      ^done,locals=[{name="A",type="int",value="1"},
>>>        {name="B",type="int",value="2"},{name="C",type="int [3]"}]
>>>      (gdb)                                             ^^^^^^^
>>>   
>> 
>> No kidding!  2 more questions then:
>> 
>> - does stack-list-args support the --simple-values option?
> 
> Does not seem so. In fact, it does not seem like -stack-list-locals support if
> either ;-). Both take an integer parameter though, passing '2' for it should
> cause only simple values to be printed.
> 
>> - how long has this feature been around?
> 
> Which? Printing types? I believe it was around for approximately -1 day.

In fact, for simple values case it was around since forever, it seems.

- Volodya

Re: -stack-list-locals and children

[Nick Roberts]

 > No kidding!  2 more questions then:
 > 
 > - does stack-list-args support the --simple-values option?

[-stack-list-arguments]

Not --simple-values directly but you can access it quite easily using the SHOW-VALUES
option which is really the PRINT-VALUES option of -stack-list-locals since the two
MI commands share the same code, namely, list_args_or_locals.

For example,

(gdb) 
-stack-list-arguments 0 0 1
^done,stack-args=[frame={level="0",args=[name="i",name="j"]},frame={level="1",args=[name="argc",name="argv"]}]
(gdb) 
-stack-list-arguments 1 0 1
^done,stack-args=[frame={level="0",args=[{name="i",value="0x7ffff7871c81"},{name="j",value="0"}]},frame={level="1",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffe7b8"}]}]
(gdb) 
--stack-list-arguments 2 0 1
^done,stack-args=[frame={level="0",args=[{name="i",type="int *",value="0x7ffff7871c81"},{name="j",type="int",value="0"}]},frame={level="1",args=[{name="argc",type="int",value="1"},{name="argv",type="char **",value="0x7fffffffe7b8"}]}]
(gdb) 

as SHOW-VALUES=2 corresponds to --simple-values.


 > - how long has this feature been around?

Since GDB 6.1, which goes back to the start of 2004.  I added --simple-values
(and documented it) for the locals buffer in Emacs but it's availability to
-stack-list-arguments was just a side effect, so I never documented that.

I think it would be quite easy to change -stack-list-arguments to accept
--no-values, --simple-values and --all-values if people want it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: -stack-list-locals and children

[Pawel Piech]

Thank you, this is very helpful. 
-Pawel

Nick Roberts wrote:
>  > No kidding!  2 more questions then:
>  > 
>  > - does stack-list-args support the --simple-values option?
>
> [-stack-list-arguments]
>
> Not --simple-values directly but you can access it quite easily using the SHOW-VALUES
> option which is really the PRINT-VALUES option of -stack-list-locals since the two
> MI commands share the same code, namely, list_args_or_locals.
>
> For example,
>
> (gdb) 
> -stack-list-arguments 0 0 1
> ^done,stack-args=[frame={level="0",args=[name="i",name="j"]},frame={level="1",args=[name="argc",name="argv"]}]
> (gdb) 
> -stack-list-arguments 1 0 1
> ^done,stack-args=[frame={level="0",args=[{name="i",value="0x7ffff7871c81"},{name="j",value="0"}]},frame={level="1",args=[{name="argc",value="1"},{name="argv",value="0x7fffffffe7b8"}]}]
> (gdb) 
> --stack-list-arguments 2 0 1
> ^done,stack-args=[frame={level="0",args=[{name="i",type="int *",value="0x7ffff7871c81"},{name="j",type="int",value="0"}]},frame={level="1",args=[{name="argc",type="int",value="1"},{name="argv",type="char **",value="0x7fffffffe7b8"}]}]
> (gdb) 
>
> as SHOW-VALUES=2 corresponds to --simple-values.
>
>
>  > - how long has this feature been around?
>
> Since GDB 6.1, which goes back to the start of 2004.  I added --simple-values
> (and documented it) for the locals buffer in Emacs but it's availability to
> -stack-list-arguments was just a side effect, so I never documented that.
>
> I think it would be quite easy to change -stack-list-arguments to accept
> --no-values, --simple-values and --all-values if people want it.
>
>   

Re: -stack-list-locals and children

[Pawel Piech]

Pawel Piech wrote:
> Thank you, this is very helpful. -Pawel
>
> Nick Roberts wrote:
>>
>> [-stack-list-arguments]
>> <snip>
>> I think it would be quite easy to change -stack-list-arguments to accept
>> --no-values, --simple-values and --all-values if people want it.
BTW, I don't think the verbose option names are needed.  It is supposed 
to be a "machine interface" after all...

Cheers,
Pawel

Re: -stack-list-locals and children

[Vladimir Prus]

André Pönitz wrote:

> On Monday 29 June 2009 11:39:27 Vladimir Prus wrote:
>> > One point was always to reduce the number of roundtrips before
>> > being able to display the variable view. I think that's a valid point
>> > also from a KDevelop angle of view.
>> 
>> Right, but how variable type is helping? Is it used *just* to populate
>> the "type" field in variable view? Or is it also involved in QtCreator's
>> pretty-printing mechanisms somehow?
> 
> Right. They are also primary information for the current incarnation of
> Qt Creator's pretty-printing.
> 
> However I don't want center the argumentation around the needs of
> a specific IDE though if there is a "cross-IDE" reason. And reducing
> roundtrip count should be fairly cross-IDE ;-}

To summarise yesterday's IRC discussion and today's commits:

1. -stack-list-locals --simple-values does print type.
2. -stack-list-arguments did not accept --simple-values, but instead
accepted a numerical '2' to mean the same. I've now checked in a patch
to make it accept --simple-values as well.
3. Making -stack-list-locals and -stack-list-arguments always print
the type is a simple -- does it seem desirable? I would
say yes, unless we expect frontend to do some other mechanism to discover
types of complex variables.

- Volodya

Re: -stack-list-locals and children

[Nick Roberts]

> > It can be expensive to make variable objects from all the locals every time
 > > the frame changes but this is what Insight does, and Apple GDB has MI code
 > > to do it.  So maybe Xcode does too.
 > 
 > Apple creates variables automatically and it is not slow.

It will surely depend on the program that you are debugging and the number
and nature of the local variables.

-- 
Nick                                           http://www.inet.net.nz/~nickrob