From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22005 invoked by alias); 19 May 2007 23:08:56 -0000 Received: (qmail 21995 invoked by uid 22791); 19 May 2007 23:08:56 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 19 May 2007 23:08:52 +0000 Received: from kahikatea.snap.net.nz (188.60.255.123.dynamic.snap.net.nz [123.255.60.188]) by viper.snap.net.nz (Postfix) with ESMTP id 0ED1B3D92AE; Sun, 20 May 2007 11:08:49 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id 45E068F92B; Sun, 20 May 2007 11:08:47 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17999.33661.331676.464061@kahikatea.snap.net.nz> Date: Sat, 19 May 2007 23:08:00 -0000 To: Maxim Grigoriev Cc: Daniel Jacobowitz , gdb@sourceware.org, Pete MacLiesh , Vinay Pandit , Shaiju P , Marc Gauthier Subject: Re: Which MI behavior is correct ? In-Reply-To: <464F51B5.5040802@hq.tensilica.com> 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> <464F51B5.5040802@hq.tensilica.com> X-Mailer: VM 7.19 under Emacs 22.0.99.3 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/msg00092.txt.bz2 > > 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