From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12650 invoked by alias); 21 May 2007 03:43:36 -0000 Received: (qmail 12638 invoked by uid 22791); 21 May 2007 03:43:34 -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; Mon, 21 May 2007 03:43:32 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1Hpynv-0004NY-DH; Sun, 20 May 2007 20:43:27 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15648-05; Sun, 20 May 2007 20:43:27 -0700 (PDT) Received: from maxim_fc5.hq.tensilica.com ([192.168.11.68]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1Hpynu-0004NS-Sk; Sun, 20 May 2007 20:43:27 -0700 Message-ID: <4651155D.7070509@hq.tensilica.com> Date: Mon, 21 May 2007 03:43:00 -0000 From: Maxim Grigoriev User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Nick Roberts CC: Maxim Grigoriev , Daniel Jacobowitz , 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> <464F51B5.5040802@hq.tensilica.com> <17999.33661.331676.464061@kahikatea.snap.net.nz> In-Reply-To: <17999.33661.331676.464061@kahikatea.snap.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00095.txt.bz2 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? > >