Which MI behavior is correct ?

Which MI behavior is correct ?

[Maxim Grigoriev]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

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="true",type_changed="false"}]
(gdb)
229^done,changelist=[{name="var4",in_scope="true",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="false"}]
(gdb)
229^done,changelist=[{name="var4",in_scope="false"}]
(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













[-- Attachment #2: CMD --]
[-- Type: text/plain, Size: 950 bytes --]

100-gdb-set confirm off
101-gdb-set width 0
102-gdb-set height 0
103-interpreter-exec console echo
104-gdb-show prompt
file exe
200-break-insert create_var.cxx:14
201-break-insert create_var.cxx:7
202-data-list-register-names
203-stack-info-depth
204-break-insert -t main
run
206-stack-info-depth
207-stack-list-frames 0 1
208-data-list-changed-registers
209-stack-list-arguments 0 0 0
210-stack-list-locals 0
211-var-create - * a
212-var-create - * b
213-var-evaluate-expression var2
214-var-evaluate-expression var1
215-exec-continue
216-stack-info-depth
217-stack-list-frames 0 2
218-data-list-changed-registers
219-stack-list-arguments 0 0 0
220-stack-list-locals 0
221-var-create - * b
222-var-create - * a
223-var-evaluate-expression var4
224-var-evaluate-expression var3
225-exec-continue
226-stack-info-depth
227-stack-list-frames 0 2
228-var-update var3
229-var-update var4
230-var-evaluate-expression var4
231-var-evaluate-expression var3


[-- Attachment #3: NATIVE.log --]
[-- Type: text/x-log, Size: 3054 bytes --]

(gdb) 
100^done
(gdb) 
101^done
(gdb) 
102^done
(gdb) 
103^done
(gdb) 
104^done,value="(gdb) "
(gdb) 
&"file exe\n"
~"Using host libthread_db library \"/lib/libthread_db.so.1\".\n"
^done
(gdb) 
200^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0804845f",func="f1(int)",file="create_var.cxx",line="14",times="0"}
(gdb) 
201^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x08048443",func="f11(int)",file="create_var.cxx",line="7",times="0"}
(gdb) 
202^done,register-names=["eax","ecx","edx","ebx","esp","ebp","esi","edi","eip","eflags","cs","ss","ds","es","fs","gs","st0","st1","st2","st3","st4","st5","st6","st7","fctrl","fstat","ftag","fiseg","fioff","foseg","fooff","fop","xmm0","xmm1","xmm2","xmm3","xmm4","xmm5","xmm6","xmm7","mxcsr","orig_eax","mm0","mm1","mm2","mm3","mm4","mm5","mm6","mm7"]
(gdb) 
&"mi_cmd_stack_info_depth: No stack.\n"
203^error,msg="mi_cmd_stack_info_depth: No stack."
(gdb) 
204^done,bkpt={number="3",type="breakpoint",disp="del",enabled="y",addr="0x08048464",func="main",file="create_var.cxx",line="17",times="0"}
(gdb) 
&"run\n"
^done,thread-id="0",frame={addr="0x08048464",func="main",args=[],file="create_var.cxx",line="17"}
(gdb) 
206^done,depth="1"
(gdb) 
207^done,stack=[frame={level="0",addr="0x08048464",func="main",file="create_var.cxx",line="17"}]
(gdb) 
208^done,changed-registers=["0","1","2","3","4","5","6","8","9","10","11","12","13","15","24","26","40","41"]
(gdb) 
209^done,stack-args=[frame={level="0",args=[]}]
(gdb) 
210^done,locals=[name="a",name="b"]
(gdb) 
211^done,name="var1",numchild="0",type="int"
(gdb) 
212^done,name="var2",numchild="0",type="int"
(gdb) 
213^done,value="11553984"
(gdb) 
214^done,value="12808180"
(gdb) 
215^running
(gdb) 
215*stopped,reason="breakpoint-hit",bkptno="2",thread-id="0",frame={addr="0x08048443",func="f11",args=[{name="b",value="1"}],file="create_var.cxx",line="7"}
(gdb) 
216^done,depth="2"
(gdb) 
217^done,stack=[frame={level="0",addr="0x08048443",func="f11",file="create_var.cxx",line="7"},frame={level="1",addr="0x08048487",func="main",file="create_var.cxx",line="22"}]
(gdb) 
218^done,changed-registers=["0","1","4","5","8","9"]
(gdb) 
219^done,stack-args=[frame={level="0",args=[name="b"]}]
(gdb) 
220^done,locals=[name="a"]
(gdb) 
221^done,name="var3",numchild="0",type="int"
(gdb) 
222^done,name="var4",numchild="0",type="int"
(gdb) 
223^done,value="2"
(gdb) 
224^done,value="1"
(gdb) 
225^running
(gdb) 
225*stopped,reason="breakpoint-hit",bkptno="2",thread-id="0",frame={addr="0x08048443",func="f11",args=[{name="b",value="2"}],file="create_var.cxx",line="7"}
(gdb) 
226^done,depth="2"
(gdb) 
227^done,stack=[frame={level="0",addr="0x08048443",func="f11",file="create_var.cxx",line="7"},frame={level="1",addr="0x08048495",func="main",file="create_var.cxx",line="23"}]
(gdb) 
228^done,changelist=[{name="var3",in_scope="true",type_changed="false"}]
(gdb) 
229^done,changelist=[{name="var4",in_scope="true",type_changed="false"}]
(gdb) 
230^done,value="3"
(gdb) 
231^done,value="2"
(gdb) 
&"\n"
^done
(gdb) 

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: XTENSA.log --]
[-- Type: text/x-log; name="XTENSA.log", Size: 4622 bytes --]

(gdb) 
100^done
(gdb) 
101^done
(gdb) 
102^done
(gdb) 
103^done
(gdb) 
104^done,value="(xt-gdb) "
(gdb) 
&"file exe\n"
^done
(gdb) 
200^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x40000978",func="f1(int)",file="create_var.cxx",fullname="/home/maxim/W/BUGS/PMAC_MI/create_var.cxx",line="14",times="0"}
(gdb) 
201^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="0x40000991",func="f11(int)",file="create_var.cxx",fullname="/home/maxim/W/BUGS/PMAC_MI/create_var.cxx",line="7",times="0"}
(gdb) 
202^done,register-names=["br","ar0","ar1","ar2","ar3","ar4","ar5","ar6","ar7","ar8","ar9","ar10","ar11","ar12","ar13","ar14","ar15","ar16","ar17","ar18","ar19","ar20","ar21","ar22","ar23","ar24","ar25","ar26","ar27","ar28","ar29","ar30","ar31","ar32","ar33","ar34","ar35","ar36","ar37","ar38","ar39","ar40","ar41","ar42","ar43","ar44","ar45","ar46","ar47","ar48","ar49","ar50","ar51","ar52","ar53","ar54","ar55","ar56","ar57","ar58","ar59","ar60","ar61","ar62","ar63","m0","m1","m2","m3","lbeg","lend","lcount","acclo","acchi","mmid","ddr","interrupt","intset","intclear","ccount","icount","ccompare0","ccompare1","epc1","epc2","epc3","excsave1","excsave2","excsave3","eps2","eps3","exccause","depc","excvaddr","windowbase","windowstart","sar","litbase","ps","intenable","dbreaka0","dbreakc0","dbreaka1","dbreakc1","ibreaka0","ibreaka1","ibreakenable","icountlevel","debugcause","cpenable","pc","a0","a1","a2","a3","a4","a5","a6","a7","a8","a9","a10","a11","a12","a13","a14","a15","b0","b1","b2","b3","b4","b5","b6","b7","b8","b9","b10","b11","b12","b13","b14","b15","psintlevel","psum","pswoe","psexcm","pscallinc","psowb","litbaddr","litben","acc","dbnum","fp"]
(gdb) 
&"No registers.\n"
203^error,msg="No registers."
(gdb) 
204^done,bkpt={number="3",type="breakpoint",disp="del",enabled="y",addr="0x40000937",func="main",file="create_var.cxx",fullname="/home/maxim/W/BUGS/PMAC_MI/create_var.cxx",line="19",times="0"}
(gdb) 
&"run\n"
~"Starting the ISS simulator.\n"
~"Switching to remote protocol\n"
~"Remote debugging using localhost:56386\n"
~"main () at create_var.cxx:19\n"
~"19\t\tint a=1;\n"
^done
(gdb) 
206^done,depth="1"
(gdb) 
207^done,stack=[frame={level="0",addr="0x40000937",func="main",file="create_var.cxx",fullname="/home/maxim/W/BUGS/PMAC_MI/create_var.cxx",line="19"}]
(gdb) 
208^done,changed-registers=["2","3","5","6","7","8","9","10","11","13","14","17","21","22","23","24","79","87","94","95","98","109","110","111","112","113","114","115","116","117","119","120","123","144","145","147","153"]
(gdb) 
209^done,stack-args=[frame={level="0",args=[]}]
(gdb) 
210^done,locals=[name="a",name="b"]
(gdb) 
211^done,name="var1",numchild="0",type="int"
(gdb) 
212^done,name="var2",numchild="0",type="int"
(gdb) 
213^done,value="0"
(gdb) 
214^done,value="0"
(gdb) 
215^running
(gdb) 
215*stopped,reason="breakpoint-hit",bkptno="2",thread-id="0",frame={addr="0x40000991",func="f11",args=[{name="b",value="1"}],file="create_var.cxx",fullname="/home/maxim/W/BUGS/PMAC_MI/create_var.cxx",line="7"}
(gdb) 
216^done,depth="2"
(gdb) 
217^done,stack=[frame={level="0",addr="0x40000991",func="f11",file="create_var.cxx",fullname="/home/maxim/W/BUGS/PMAC_MI/create_var.cxx",line="7"},frame={level="1",addr="0x40000940",func="main",file="create_var.cxx",fullname="/home/maxim/W/BUGS/PMAC_MI/create_var.cxx",line="22"}]
(gdb) 
218^done,changed-registers=["13","14","15","16","17","79","94","95","98","110","111","112","114","115","116","117","119","120","121","122","123","147","153"]
(gdb) 
219^done,stack-args=[frame={level="0",args=[name="b"]}]
(gdb) 
220^done,locals=[name="a"]
(gdb) 
221^done,name="var3",numchild="0",type="int"
(gdb) 
222^done,name="var4",numchild="0",type="int"
(gdb) 
223^done,value="2"
(gdb) 
224^done,value="1"
(gdb) 
225^running
(gdb) 
225*stopped,reason="breakpoint-hit",bkptno="2",thread-id="0",frame={addr="0x40000991",func="f11",args=[{name="b",value="2"}],file="create_var.cxx",fullname="/home/maxim/W/BUGS/PMAC_MI/create_var.cxx",line="7"}
(gdb) 
226^done,depth="2"
(gdb) 
227^done,stack=[frame={level="0",addr="0x40000991",func="f11",file="create_var.cxx",fullname="/home/maxim/W/BUGS/PMAC_MI/create_var.cxx",line="7"},frame={level="1",addr="0x40000947",func="main",file="create_var.cxx",fullname="/home/maxim/W/BUGS/PMAC_MI/create_var.cxx",line="23"}]
(gdb) 
228^done,changelist=[{name="var3",in_scope="false"}]
(gdb) 
229^done,changelist=[{name="var4",in_scope="false"}]
(gdb) 
230^done,value="2"
(gdb) 
231^done,value="1"
(gdb) 
&"\n"
^done
(gdb) 

Re: Which MI behavior is correct ?

[Maxim Grigoriev]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

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="true",type_changed="false"}]
> (gdb)
> 229^done,changelist=[{name="var4",in_scope="true",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="false"}]
> (gdb)
> 229^done,changelist=[{name="var4",in_scope="false"}]
> (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
>
>
>
>
>
>


[-- Attachment #2: create_var.cxx --]
[-- Type: text/x-c++src, Size: 245 bytes --]

#include <stdio.h>

int f11(int b)
{
	int a;
	a = b + 1;
	return a;
}

int f1(int a)
{
	int b;
	b = f11(a) + 1;
	return b;
}

int main()
{
	int a=1;
	int b;
	
	a = f11(a);
	a = f11(a);
	b = f1(a);
	
	printf("a,b: %d,%d\n", a, b);
	
	return 0;
}

Re: Which MI behavior is correct ?

[Nick Roberts]

 > 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="true",type_changed="false"}]
 > (gdb)
 > 229^done,changelist=[{name="var4",in_scope="true",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="false"}]
 > (gdb)
 > 229^done,changelist=[{name="var4",in_scope="false"}]
 > (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.nz/~nickrob

Re: Which MI behavior is correct ?

[Daniel Jacobowitz]

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

Re: Which MI behavior is correct ?

[Nick Roberts]

 > >  >     - 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.nz/~nickrob

Re: Which MI behavior is correct ?

[Maxim Grigoriev]

[-- Attachment #1: Type: text/plain, Size: 2789 bytes --]

Nick, Daniel, thanks much for your comments.

My test case wasn't simple enough. Now, I hope it's more clear:

newtest.c:
---------------------------------------------
int f11(int b)
{
  int a;

  a = b + 1;
  return a;   /* <- BP set here.  */
}

int main()
{
  int a = 1;

  a = f11(a);
  a = f11(a);
 
  return a;
}

MI commands used (CMD):
----------------------------------------------
100-interpreter-exec console echo
file exe
200-break-insert newtest.c:6
run
300-var-create - * a
301-var-create - * b
302-var-evaluate-expression var1
303-var-evaluate-expression var2
400-exec-continue
500-var-update var1
501-var-update var2
502-var-evaluate-expression var1
503-var-evaluate-expression var2
kill
quit

Debuggers ran with commands:
xt-gdb -q -nw --interpreter=mi <CMD >XTENSA.log
gdb -q -nw --interpreter=mi <CMD >NATIVE.log

The outputs are attached.

 > 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.

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.

-- Maxim


Nick Roberts wrote:
>  > >  >     - 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.
>
>
>
>   


[-- Attachment #2: NATIVE.log --]
[-- Type: text/x-log, Size: 997 bytes --]

(gdb) 
100^done
(gdb) 
&"file exe\n"
~"Using host libthread_db library \"/lib/libthread_db.so.1\".\n"
^done
(gdb) 
200^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x08048363",func="f11",file="newtest.c",line="6",times="0"}
(gdb) 
&"run\n"
^done,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x08048363",func="f11",args=[{name="b",value="1"}],file="newtest.c",line="6"}
(gdb) 
300^done,name="var1",numchild="0",type="int"
(gdb) 
301^done,name="var2",numchild="0",type="int"
(gdb) 
302^done,value="2"
(gdb) 
303^done,value="1"
(gdb) 
400^running
(gdb) 
400*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x08048363",func="f11",args=[{name="b",value="2"}],file="newtest.c",line="6"}
(gdb) 
500^done,changelist=[{name="var1",in_scope="true",type_changed="false"}]
(gdb) 
501^done,changelist=[{name="var2",in_scope="true",type_changed="false"}]
(gdb) 
502^done,value="3"
(gdb) 
503^done,value="2"
(gdb) 
&"kill\n"
^done
(gdb) 
&"quit\n"

[-- Attachment #3: XTENSA.log --]
[-- Type: text/x-log, Size: 1024 bytes --]

(gdb) 
100^done
(gdb) 
&"file exe\n"
~"Reading symbols from /home/maxim/W/BUGS/PMAC_MI/exe..."
~"done.\n"
^done
(gdb) 
200^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x40000465",func="f11",file="newtest.c",fullname="/home/maxim/W/BUGS/PMAC_MI/newtest.c",line="6",times="0"}
(gdb) 
&"run\n"
~"Breakpoint 1, f11 (b=1) at newtest.c:6\n"
~"6\t  return a;   /* <- BP set here.  */\n"
^done
(gdb) 
300^done,name="var1",numchild="0",value="2",type="int"
(gdb) 
301^done,name="var2",numchild="0",value="1",type="int"
(gdb) 
302^done,value="2"
(gdb) 
303^done,value="1"
(gdb) 
400^running
(gdb) 
400*stopped,reason="breakpoint-hit",bkptno="1",thread-id="0",frame={addr="0x40000465",func="f11",args=[{name="b",value="2"}],file="newtest.c",fullname="/home/maxim/W/BUGS/PMAC_MI/newtest.c",line="6"}
(gdb) 
500^done,changelist=[{name="var1",in_scope="false"}]
(gdb) 
501^done,changelist=[{name="var2",in_scope="false"}]
(gdb) 
502^done,value=""
(gdb) 
503^done,value=""
(gdb) 
&"kill\n"
^done
(gdb) 
&"quit\n"

Re: Which MI behavior is correct ?

[Nick Roberts]

 >  > 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.nz/~nickrob

Re: Which MI behavior is correct ?

[Maxim Grigoriev]

Hi Nick and Daniel,

You're right. It's an Xtensa-specific difference in the MI behavior.

I built native GNU Linux-X86 gdb from the top of the FSF tree, and it's
consistent with anything else but GNU Xtensa gdb.

I have to fix Xtensa gdb. When I implemented frame ID Xtensa functions
I followed an advice from GDB expert(s) and choose

    - physical Return Address of the current frame and
    - Stack Pointer of the previous frame

to identify frames.

So there is probably nothing wrong about this choice. It's supposed
to work for MI variable objects as well. Let's see what did I miss.

Thanks much for your valuable inputs on this issue,

-- Maxim

Nick Roberts wrote:
>  >  > 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?
>
>   

Re: Which MI behavior is correct ?

[Jim Blandy]

Maxim Grigoriev <maxim@tensilica.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

Re: Which MI behavior is correct ?

[Maxim Grigoriev]

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 <maxim@tensilica.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
>