From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11668 invoked by alias); 22 May 2007 20:45:40 -0000 Received: (qmail 11654 invoked by uid 22791); 22 May 2007 20:45: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; Tue, 22 May 2007 20:45:28 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HqbET-00040C-5e; Tue, 22 May 2007 13:45:25 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14822-08; Tue, 22 May 2007 13:45:24 -0700 (PDT) Received: from maxim_fc5.hq.tensilica.com ([192.168.11.68]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HqbES-000406-Lv; Tue, 22 May 2007 13:45:24 -0700 Message-ID: <46535664.4090705@hq.tensilica.com> Date: Tue, 22 May 2007 20:45:00 -0000 From: Maxim Grigoriev User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Nick Roberts CC: Maxim Grigoriev , Jim Blandy , gdb@sourceware.org, Marc Gauthier , Pete MacLiesh , Ross Morley 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/msg00122.txt.bz2 > But does this explain why xt-gdb didn't detect the > variable objects coming back > into scope when an i386 gdb did? Yes, it does. Thanks to Ross, who already explained it in the previous email on this thread. > Actually I think we've discussed this behavior before > and done nothing about it. I suggest we improve gdb documentation in the way that, when we don't have time to describe things properly, we at least put a reference to a corresponding GDB-mailing-list discussion. -- Maxim 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? > > > 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. > >