From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9015 invoked by alias); 23 May 2007 00:32:38 -0000 Received: (qmail 9004 invoked by uid 22791); 23 May 2007 00:32:37 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 May 2007 00:32:34 +0000 Received: (qmail 15541 invoked from network); 23 May 2007 00:32:30 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 23 May 2007 00:32:30 -0000 To: Ross Morley 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> <46538818.1050601@tensilica.com> From: Jim Blandy Date: Wed, 23 May 2007 00:32:00 -0000 In-Reply-To: <46538818.1050601@tensilica.com> (Ross Morley's message of "Tue, 22 May 2007 17:17:28 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00129.txt.bz2 Ross Morley writes: > 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. I don't follow. Is there something here where a frame's return address and entry point change, but it's not a new frame? I'm not claiming using both the return address and the entry point would eliminate false positives in frame_eq, just that it restricts false positives and does not introduce false negatives.