From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23722 invoked by alias); 19 May 2007 19:36:37 -0000 Received: (qmail 23713 invoked by uid 22791); 19 May 2007 19:36:36 -0000 X-Spam-Check-By: sourceware.org Received: from hq.tensilica.com (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 19 May 2007 19:36:29 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HpUj0-0003x6-Pc; Sat, 19 May 2007 12:36:22 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14625-08; Sat, 19 May 2007 12:36:22 -0700 (PDT) Received: from maxim_fc5.hq.tensilica.com ([192.168.11.68]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HpUj0-0003wy-4W; Sat, 19 May 2007 12:36:22 -0700 Message-ID: <464F51B5.5040802@hq.tensilica.com> Date: Sat, 19 May 2007 19:36:00 -0000 From: Maxim Grigoriev User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Nick Roberts CC: Daniel Jacobowitz , Maxim Grigoriev , gdb@sourceware.org, Pete MacLiesh , Vinay Pandit , Shaiju P , Marc Gauthier Subject: Re: Which MI behavior is correct ? References: <464E4C4D.9010709@hq.tensilica.com> <17998.24266.849023.454806@kahikatea.snap.net.nz> <20070519030245.GA941@caradoc.them.org> <17998.28300.327133.525945@kahikatea.snap.net.nz> In-Reply-To: <17998.28300.327133.525945@kahikatea.snap.net.nz> Content-Type: multipart/mixed; boundary="------------070706000602050106020703" X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-05/txt/msg00089.txt.bz2 This is a multi-part message in MIME format. --------------070706000602050106020703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-length: 2789 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 XTENSA.log gdb -q -nw --interpreter=mi 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. > > > > --------------070706000602050106020703 Content-Type: text/x-log; name="NATIVE.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="NATIVE.log" Content-length: 997 (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" --------------070706000602050106020703 Content-Type: text/x-log; name="XTENSA.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="XTENSA.log" Content-length: 1024 (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" --------------070706000602050106020703--