From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10977 invoked by alias); 5 Mar 2005 18:13:31 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 10931 invoked from network); 5 Mar 2005 18:13:24 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 5 Mar 2005 18:13:24 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id j25IDDi0009069; Sat, 5 Mar 2005 19:13:13 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id j25IDCqp016726; Sat, 5 Mar 2005 19:13:12 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id j25IDCxt016723; Sat, 5 Mar 2005 19:13:12 +0100 (CET) Date: Sat, 05 Mar 2005 18:13:00 -0000 Message-Id: <200503051813.j25IDCxt016723@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sources.redhat.com In-reply-to: <20050305164451.GA8398@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 5 Mar 2005 11:44:52 -0500) Subject: Re: [RFA] New GDB target iq2000 References: <20050222114141.GA18314@cygbert.vinschen.de> <20050303173443.GD18681@nevyn.them.org> <20050304094605.GU2839@cygbert.vinschen.de> <20050304141439.GA30249@nevyn.them.org> <20050304150129.GF2839@cygbert.vinschen.de> <20050304220104.GA14522@nevyn.them.org> <200503051128.j25BSruw007318@elgar.sibelius.xs4all.nl> <20050305164451.GA8398@nevyn.them.org> X-SW-Source: 2005-03/txt/msg00063.txt.bz2 Date: Sat, 5 Mar 2005 11:44:52 -0500 From: Daniel Jacobowitz On Sat, Mar 05, 2005 at 12:28:53PM +0100, Mark Kettenis wrote: > Date: Fri, 4 Mar 2005 17:01:04 -0500 > From: Daniel Jacobowitz > > I left the other function alone. skip_prologue_using_sal is already a > bit bogus, for the reasons identified by Kevin as well as for at least > one other that I can see. find_last_line_symbol is even boguser. > Basically, any code that compares the LINE member of two arbitrary SALs > _must_ be wrong. They don't even need to be in the same source file. > > Another issue with skip_prologue_using_sal() is that it will happily > skip the entire function if the function body is basically empty. I > really think it should be deprecated, and shouldn't be used in any new > code. Hum... so it will. I rather think it should be fixed. I have a patch to fix the most common occurance of that, when the line notes look like: line1: line2: ret For a compiler which doesn't use the two line note convention, of course, it's bogus - but so is lots of the rest of GDB. That's not an excuse for not trying to come up with an algorithm that's more robust. Attached is the patch that I have sitting in my tree. Could you explain why you think it should be deprecated? Bear in mind that it's _new_ - it was derived from various similar things in tdep files, in an attempt to commonize. And it was never properly tested. And there was never a coordinated attempt to use this common code. > There's two things that GDB uses the guessed prologue line information > for. One is to place an initial breakpoint, so that the arguments have > been saved. This problem will hopefully eventually go away, with > improved GCC -fvar-tracking - we should be able to print the arguments > from anywhere. Someone needs to spend a little love on the compiler > side of this. > > The important thing about placing the initial breakpoint, is that it > shouldn't be placed too far into the function. In particular it > should not end up after a branch instruction. Yes. I mentioned to Kevin off-list that I've been thinking about an ideal paradigm for implementing both this and prologue scanners. What we need is a common simulator architecture which can "describe" the effects of instructions - enough instructions to handle prologues, at least. A huge project for someday :-) That suggestion has been made more than once in the past; I don't really consider this viable for architectures where instructions aren't fixed length. Anyway, I think most problems are caused because we are trying to use the same code for two distinct cases: (a) getting an upper limit for the prologue end and (b) getting a lower limit for the prologue end. Combining (a) and (b) results in having to determine the end of the prologue exactly, which is much harder. Mark Index: symtab.c =================================================================== RCS file: /cvs/src/src/gdb/symtab.c,v retrieving revision 1.144 diff -u -p -r1.144 symtab.c --- symtab.c 15 Feb 2005 15:49:21 -0000 1.144 +++ symtab.c 5 Mar 2005 18:12:51 -0000 @@ -4050,6 +4050,11 @@ skip_prologue_using_sal (CORE_ADDR func_ prologue_sal = sal; } } + + /* Avoid skipping the entire function. */ + if (prologue_sal.end >= end_pc) + return 0; + return prologue_sal.end; }