Which MI behavior is correct ?

Hello GDB experts,

I wonder if somebody can help me to understand which
GDB MI behavior is supposed to be correct.

I've included the test case, the MI commands used, and
the outputs from two debuggers: the native FC5 Linux-X86

    GNU gdb Red Hat Linux (6.3.0.0-1.134.fc5rh)

and ours

    GNU gdb 6.5 Xtensa Tools 7.1.0-development

Our GNU gdb 6.5 is consistent with the top of the FSF tree.


PROBLEM DESCRIPTION:
====================

When we hit the breakpoint inside f11() second time:

In case of 6.3 we have :

228^done,changelist=[{name="var3",in_scope="t
rue",type_changed="false"}]
(gdb)
229^done,changelist=[{name="var4",in_scope="t
rue",type_changed="false"}]
(gdb)
230^done,value="3"
(gdb)
231^done,value="2"
(gdb)

In in case of 6.5+ we have :

228^done,changelist=[{name="var3",in_scope="f
alse"}]
(gdb)
229^done,changelist=[{name="var4",in_scope="f
alse"}]
(gdb)
230^done,value="2"
(gdb)
231^done,value="1"
(gdb)

So "var3" and "var4" are out of scope.

Our GUI front-end relies on the 6.3-like behavior, which is
consistent with
what we had in our previous releases based on GNU gdb
5.2.1.

QUESTIONS
=========

1) Is 6.5(+)-style behavior incorrect ?

   If it is correct:

    - Are we supposed to recreate variables each time we
enter the 
function ?
    - Is this efficient ?

2) Where can I find a good documentation describing these
aspects of GDB 
MI ?
   All docs I found on the Internet weren't quite helpful.

Thanks in advance for any of your help.

-- Maxim

The test case wasn't included:

Now, it is.

-- Maxim

Maxim Grigoriev wrote:
> Hello GDB experts,
>
> I wonder if somebody can help me to understand which
> GDB MI behavior is supposed to be correct.
>
> I've included the test case, the MI commands used, and
> the outputs from two debuggers: the native FC5
Linux-X86
>
>    GNU gdb Red Hat Linux (6.3.0.0-1.134.fc5rh)
>
> and ours
>
>    GNU gdb 6.5 Xtensa Tools 7.1.0-development
>
> Our GNU gdb 6.5 is consistent with the top of the FSF
tree.
>
>
> PROBLEM DESCRIPTION:
> ====================
>
> When we hit the breakpoint inside f11() second time:
>
> In case of 6.3 we have :
>
>
228^done,changelist=[{name="var3",in_scope="t
rue",type_changed="false"}]
> (gdb)
>
229^done,changelist=[{name="var4",in_scope="t
rue",type_changed="false"}]
> (gdb)
> 230^done,value="3"
> (gdb)
> 231^done,value="2"
> (gdb)
>
> In in case of 6.5+ we have :
>
>
228^done,changelist=[{name="var3",in_scope="f
alse"}]
> (gdb)
>
229^done,changelist=[{name="var4",in_scope="f
alse"}]
> (gdb)
> 230^done,value="2"
> (gdb)
> 231^done,value="1"
> (gdb)
>
> So "var3" and "var4" are out of
scope.
>
> Our GUI front-end relies on the 6.3-like behavior,
which is consistent 
> with
> what we had in our previous releases based on GNU gdb
5.2.1.
>
> QUESTIONS
> =========
>
> 1) Is 6.5(+)-style behavior incorrect ?
>
>   If it is correct:
>
>    - Are we supposed to recreate variables each time we
enter the 
> function ?
>    - Is this efficient ?
>
> 2) Where can I find a good documentation describing
these aspects of 
> GDB MI ?
>   All docs I found on the Internet weren't quite
helpful.
>
> Thanks in advance for any of your help.
>
> -- Maxim
>
>
>
>
>
>

 > PROBLEM DESCRIPTION:
 > ====================
 > 
 > When we hit the breakpoint inside f11() second time:
 > 
 > In case of 6.3 we have :
 > 
 >
228^done,changelist=[{name="var3",in_scope="t
rue",type_changed="false"}]
 > (gdb)
 >
229^done,changelist=[{name="var4",in_scope="t
rue",type_changed="false"}]
 > (gdb)
 > 230^done,value="3"
 > (gdb)
 > 231^done,value="2"
 > (gdb)
 > 
 > In in case of 6.5+ we have :
 > 
 >
228^done,changelist=[{name="var3",in_scope="f
alse"}]
 > (gdb)
 >
229^done,changelist=[{name="var4",in_scope="f
alse"}]
 > (gdb)
 > 230^done,value="2"
 > (gdb)
 > 231^done,value="1"
 > (gdb)
 > 
 > So "var3" and "var4" are out of
scope.
 > 
 > Our GUI front-end relies on the 6.3-like behavior,
which is consistent with
 > what we had in our previous releases based on GNU gdb
5.2.1.
 > 
 > QUESTIONS
 > =========
 > 
 > 1) Is 6.5(+)-style behavior incorrect ?

That's a loaded question.  Your comparing apples and pears. 
For a true
comparison you should compare GNU gdb Red Hat Linux (6.5)
(if possible)
with GNU gdb 6.5 Xtensa Tools.

The former behaviour is correct, and that's what I get with
FSF GDB 6.6

I think there is something wrong with your implementation of
GDB, or
something nonstansard about f11().

 >    If it is correct:
 > 
 >     - Are we supposed to recreate variables each time
we enter the 
 > function ?
 >     - Is this efficient ?

Well the variables themselves are reallocated from the
stack, so there's
a chance that they're not the same variables.  At the
moment, however
GDB assumes that they are the same and you don't have to
recreate them.

 > 2) Where can I find a good documentation describing
these aspects of GDB 
 > MI ?

The info manual has a section called GDB/MI.


-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Sat, May 19, 2007 at 02:19:54PM +1200, Nick Roberts
wrote:
>  >    If it is correct:
>  > 
>  >     - Are we supposed to recreate variables each
time we enter the 
>  > function ?
>  >     - Is this efficient ?
> 
> Well the variables themselves are reallocated from the
stack, so there's
> a chance that they're not the same variables.  At the
moment, however
> GDB assumes that they are the same and you don't have
to recreate them.

Aren't the variables associated with a particular frame ID? 
I thought
we'd decided that it was the right thing to take them out of
scope.

-- 
Daniel Jacobowitz
CodeSourcery

 > >  >     - Are we supposed to recreate variables
each time we enter the 
 > >  > function ?
 > >  >     - Is this efficient ?
 > > 
 > > Well the variables themselves are reallocated
from the stack, so there's
 > > a chance that they're not the same variables.  At
the moment, however
 > > GDB assumes that they are the same and you don't
have to recreate them.
 > 
 > Aren't the variables associated with a particular
frame ID?  I thought
 > we'd decided that it was the right thing to take them
out of scope.

Maxim hadn't posted the test case when I replied.  Even now
I'm not sure what
the chain of events are.  If the second instance is when f11
is called by f1,
then I agree it should be out of scope, and I think it
always has been.  If it
refers to the second time f11 is called from main (and the
transcript seems to
suggest this, although I've not looked too carefully) then
GDB still considers
this to be in scope.



-- 
Nick                                           http://www.inet.net.n
z/~nickrob

 >  > Aren't the variables associated with a
particular frame ID? I thought
 >  > we'd decided that it was the right thing to take
them out of scope.
 > 
 > This seems to be an answer to my question. The
behavior has changed
 > probably since somewhere around 6.3. Now, variable
objects are associated
 > with the frame, not with the function. As you can see
in gdb 6.3 case
 > ( NATIVE.log ), variables "var1" and
"var2" were successfully reused,
 > when new frame was allocated after hitting the
breakpoint second time.
 > In 6.5+ (XTENSA.log), we have to recreate variable
objects every time
 > we have a new frame because the old variables are out
of scope.

As I said last time, I get the gdb 6.3 behaviour with FSF
GDB 6.5.  In fact
I can't see how GDB can take the variables out of scope when
the stack
address and code address are the same.

 > Correct ?
 > 
 > How about efficiency ? What if we have to create
hundreds of variable
 > objects at every breakpoint hit ?
 > 
 > We kept staying with GNU gdb 5.2.1 for too long. So it
looks like
 > we might have missed this important change, which is
already in the
 > past for the majority of GNU gdb users.

I still think you're barking up the wrong tree.  Can't you
test a stock
GDB 6.5 somewhere to see which behaviour you get?  If it has
changed can
you identify when it did from the ChangeLog?

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

Maxim Grigoriev <maximtensilica.com> writes:
> This seems to be an answer to my question. The behavior
has changed
> probably since somewhere around 6.3. Now, variable
objects are associated
> with the frame, not with the function. As you can see
in gdb 6.3 case
> ( NATIVE.log ), variables "var1" and
"var2" were successfully reused,
> when new frame was allocated after hitting the
breakpoint second time.
> In 6.5+ (XTENSA.log), we have to recreate variable
objects every time
> we have a new frame because the old variables are out
of scope.

Just to connect this old thread with newer conversation:

To avoid recreating variable objects, you probably want to
pass '' as
your frame to -var-create.  This makes the varobj re-parse
and
re-evaluate the expression using the currently selected
frame at each
update.

Old-style varobjs that use '*' or an address as their frame
should
never come back into scope once their frame is popped.  If
they do,
it's a fluke.

The '' syntax is undocumented; I posted a manual patch
based on some
experimentation and reading the code:

http://sourceware.org/ml/gdb-patches/2007-05/msg00397.
html

Thanks !

I understand we're going to have to upgrade our GNU XT-GDB
6.5 to be able
to use the '' syntax.

-- Maxim

Jim Blandy wrote:
> Maxim Grigoriev <maximtensilica.com> writes:
>   
>> This seems to be an answer to my question. The
behavior has changed
>> probably since somewhere around 6.3. Now, variable
objects are associated
>> with the frame, not with the function. As you can
see in gdb 6.3 case
>> ( NATIVE.log ), variables "var1" and
"var2" were successfully reused,
>> when new frame was allocated after hitting the
breakpoint second time.
>> In 6.5+ (XTENSA.log), we have to recreate variable
objects every time
>> we have a new frame because the old variables are
out of scope.
>>     
>
> Just to connect this old thread with newer
conversation:
>
> To avoid recreating variable objects, you probably want
to pass '' as
> your frame to -var-create.  This makes the varobj
re-parse and
> re-evaluate the expression using the currently selected
frame at each
> update.
>
> Old-style varobjs that use '*' or an address as their
frame should
> never come back into scope once their frame is popped. 
If they do,
> it's a fluke.
>
> The '' syntax is undocumented; I posted a manual patch
based on some
> experimentation and reading the code:
>
> http://sourceware.org/ml/gdb-patches/2007-05/msg00397.
html
>