From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32017 invoked by alias); 23 May 2007 00:17:38 -0000 Received: (qmail 32010 invoked by uid 22791); 23 May 2007 00:17:35 -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; Wed, 23 May 2007 00:17:32 +0000 Received: from localhost ([127.0.0.1]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HqeXg-0007oX-Tp; Tue, 22 May 2007 17:17:29 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29811-03; Tue, 22 May 2007 17:17:28 -0700 (PDT) Received: from nose.hq.tensilica.com ([192.168.11.18]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1HqeXg-0007oN-BU; Tue, 22 May 2007 17:17:28 -0700 Message-ID: <46538818.1050601@tensilica.com> Date: Wed, 23 May 2007 00:17: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: Jim Blandy CC: Maxim Grigoriev , gdb@sourceware.org, Marc Gauthier , Pete MacLiesh Subject: Re: Understanding GDB frames References: <46521C04.7040405@hq.tensilica.com> <465341B8.9060208@hq.tensilica.com> In-Reply-To: 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/msg00128.txt.bz2 Jim Blandy wrote: >Maxim Grigoriev writes: > > >>>All those frames ought to be different, but GDB will treat >>>some of them as the same. >>> >>> >>I think distinguishing frames can be improved by using the third >>argument of frame_id, which is a "special address". Most of the >>implementations don't use it. >> >> > >Yes --- that was meant for use by the IA-64, which has a separate >stack for saving registers. If you have a series of calls with frames >holding nothing but saved registers, then they may allocate no space >at all on the ordinary stack. So you need to use the register stack >pointer to distinguish frames, too. > >After I'd sent my last post I realized that, of course, the "entry >point PC" approach fails in the (I'd guess) more common case that the >"return address PC" does not: > > void foo (void) {} > main () { foo (); foo (); } > >Perhaps the best approach is to use both the return address and the >entry point in the frame ID. If either have changed, it's certainly a >new frame. > > Well not quite certainly, eg. void bar (void) {} void foo (void) { bar (); } main () { foo (); foo (); } But definitely an improvement that's easy to achieve. The problem is that the determination of the frame ID is arch specific and so the behavior in these corner cases is not well-defined for the MI client. Ross