From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2123 invoked by alias); 7 Mar 2002 18:42:03 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2056 invoked from network); 7 Mar 2002 18:42:01 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 7 Mar 2002 18:42:01 -0000 Received: from cse.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id KAA03166; Thu, 7 Mar 2002 10:41:51 -0800 (PST) Received: (from kev@localhost) by cse.cygnus.com (8.11.6/8.11.6) id g27IfSK28577; Thu, 7 Mar 2002 11:41:28 -0700 Date: Thu, 07 Mar 2002 10:42:00 -0000 From: Kevin Buettner Message-Id: <1020307184128.ZM28576@localhost.localdomain> In-Reply-To: David Mosberger "Re: question on gdbarch_skip_prologue()" (Mar 7, 10:12am) References: <1020307081116.ZM26473@localhost.localdomain> <15495.44458.890110.519531@napali.hpl.hp.com> X-Mailer: Z-Mail (4.0.1 13Jan97 Caldera) To: davidm@hpl.hp.com Subject: Re: question on gdbarch_skip_prologue() Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-03/txt/msg00057.txt.bz2 On Mar 7, 10:12am, David Mosberger wrote: > >>>>> On Thu, 7 Mar 2002 01:11:17 -0700, Kevin Buettner said: > > Kevin> GDB currently expects that the skip_prologue() function will > Kevin> return a PC that's after the last prologue instruction that > Kevin> saved an argument to its "home" location (if any) in memory > Kevin> (or whereever the debug info says that a parameter's location > Kevin> is). The difficulty with this, of course, is that with > Kevin> optimized code, it can be very difficult to discern where > Kevin> this is. > > So, if I may paraphrase, skip_prologue() returns the PC of the first > instruction for which the debug info will be valid, right? Right. But you should also know that most (all?) of us working on GDB don't really like this behavior and are eagerly waiting for the day when it'll be possible to implement skip_prologue() as the identity function (on the first argument). > If so, I'd argue this has much more to do with debug info than with > unwind info. For example, hand-written assembly routines often have > sizable prologues, but a programmer would almost certainly want a > breakpoint to be placed right at the beginning of the function, not at > the end of the prologue. That's true. > Now, I wonder whether it wouldn't be possible and indeed better to > implement skip_prologue() based on debug info. Unfortunately, I'm not > very familiar with, say, DWARF2. However, I did notice that applying > the "info line" command to the first line of source code in a C > program does indeed return a starting address that corresponds to the > value that ought to be returned by skip_prologue(). I believe that there are implementations of skip_prologue() which do exactly that. You can find a somewhat better algorithm in refine_prologue_limit() in ia64-tdep.c. (It works for optimized prologues too.) I should note that this method doesn't work well when you have a function written all on one line like this: int sum (int a, int b) { int c = a + b; return c; } > Perhaps skip_prologue() could look for the first PC that is covered by > line info and return that value (or the original PC if there is no > such PC)? To be on the safe side, skip_prologue() probably ought to > give up the search as soon as it sees a branch instruction. > > Would this be a safe algorithm? I think so, though you probably want it to stop at predicated instructions too. (Plus you should consider using the refine_prologue_limit() algorithm.) Kevin