From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26079 invoked by alias); 30 Jul 2007 22:12:19 -0000 Received: (qmail 26070 invoked by uid 22791); 30 Jul 2007 22:12:18 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Jul 2007 22:12:12 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.0/8.14.0) with ESMTP id l6UMC1Yf001573; Tue, 31 Jul 2007 00:12:01 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.0/8.14.0/Submit) id l6UMC0WN029743; Tue, 31 Jul 2007 00:12:00 +0200 (CEST) Date: Mon, 30 Jul 2007 23:07:00 -0000 Message-Id: <200707302212.l6UMC0WN029743@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: eager@eagercon.com CC: wenbo.yang@simplnano.com, mark.kettenis@xs4all.nl, gdb@sources.redhat.com In-reply-to: <46AE5570.7080202@eagercon.com> (message from Michael Eager on Mon, 30 Jul 2007 14:17:36 -0700) Subject: Re: frame cache References: <46A648BC.8070105@eagercon.com> <46A98934.5040902@simplnano.com> <46AE5570.7080202@eagercon.com> 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-07/txt/msg00214.txt.bz2 > Date: Mon, 30 Jul 2007 14:17:36 -0700 > From: Michael Eager > > >> I don't see where there is any test in symtab.c or infrun.c > >> which tests for debug info before calling SKIP_PROLOGUE which > >> calls _skip_prologue. > > > > Because if you want to use debugging information to skip prologue, you > > write the code in this function. So, test should be place here in this > > function. > > As I mentioned, in x86 or PowerPC there is no code to bypass analyzing > the prologue, even if there is debug info. If prologue analysis is > truly to be done "only as a last resort", and I agree that this should > be the case, then this seems not to be represented in the gdb code. In the context of the the frame cache, prologue analysis *is* only done as a last resort for all targets that have DWARF CFI. We have a stack of unwinders, and run down that stack until we find an unwinder that can handle a particular frame. The unwinder that does the prologue analysis comes last in that stack, after the DWARF unwinder. So if there is DWARF CFI debug info for a frame, the prologue analysis is never done. Of course in practice you're probably running lots of code that doesn't have debug info because many vendors install stripped libraries. Now on some targets we also do prologue analysis when placing a breakpoint on a function. In theory this should also be possible using DWARF debug info, except that GCC doesn't (yet) provide that information. We used to do this using line number information (and on some targets we still do that), but that became unreliable when the compiler started to agressively reschedule prologue instructions. And then there were issues with the line number information generated by GCC being wrong. However, this is only done when setting breakpoints, so it shouldn't really be happening that much, and therefore isn't very performance critical. It also doesn't really have anything to do with the frame cache. So I'm not really sure under which conditions you're observing the excessive prologue analysis. If you're seeing it during frame unwinding, it might be worth investigating why the DWARF frame unwinder doesn't handle things. Perhaps you should consider installing unstripped libraries, or seperate debug info for the libraries on your system. If you are seeing it when breakpoints get set, it is probably worth working on getting GCC to emit the proper debug info and implementing support for it in GDB. Mark