From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6280 invoked by alias); 22 May 2007 20:33:45 -0000 Received: (qmail 6269 invoked by uid 22791); 22 May 2007 20:33:44 -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; Tue, 22 May 2007 20:33:40 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1Hqb33-000290-FV; Tue, 22 May 2007 13:33:37 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08091-02; Tue, 22 May 2007 13:33:37 -0700 (PDT) Received: from nose.hq.tensilica.com ([192.168.11.18]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1Hqb33-00028u-0l; Tue, 22 May 2007 13:33:37 -0700 Message-ID: <465353A0.502@tensilica.com> Date: Tue, 22 May 2007 20:33:00 -0000 From: Ross Morley User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 MIME-Version: 1.0 To: Nick Roberts CC: Maxim Grigoriev , Jim Blandy , gdb@sourceware.org, Marc Gauthier , Pete MacLiesh Subject: Re: Understanding GDB frames References: <46521C04.7040405@hq.tensilica.com> <465341B8.9060208@hq.tensilica.com> <18003.20573.821091.352259@kahikatea.snap.net.nz> In-Reply-To: <18003.20573.821091.352259@kahikatea.snap.net.nz> Content-Type: text/plain; charset=us-ascii; 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/msg00121.txt.bz2 Nick Roberts wrote: >Maxim Grigoriev writes: > > > It's worth pointing out that the 'PC' in a frame ID isn't the current > > > PC within the function. It's always the PC of the function's entry > > > point, so that stepping within a function doesn't cause the frame ID > > > to change. Usually it's a PC value returned by 'frame_func_unwind', > > > which takes care of calling get_pc_function_start for you. > > > > We've been using a function return address instead of > > the PC of the function's entry, and it works just fine. > >But does this explain why xt-gdb didn't detect the variable objects coming back >into scope when an i386 gdb did? > > In this case it's because Xtensa uses the return address rather than the function entrypoint in the frame ID. Two calls from the same caller have different frame IDs. That's not the case in i386. Technically the variable didn't come back into scope, a new instance of it was created. It's sometimes convenient to treat it as if it came back into scope. Ross > > The good part of our approach is it allowed to expose some > > problems with MI variable objects :-) > >Actually I think we've discussed this behaviour before and done nothing about >it. > > >