From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16916 invoked by alias); 4 Mar 2005 22:01:10 -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 16900 invoked from network); 4 Mar 2005 22:01:03 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 4 Mar 2005 22:01:03 -0000 Received: from drow by nevyn.them.org with local (Exim 4.44 #1 (Debian)) id 1D7Kr2-0003sP-GY for ; Fri, 04 Mar 2005 17:01:04 -0500 Date: Fri, 04 Mar 2005 22:01:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: Re: [RFA] New GDB target iq2000 Message-ID: <20050304220104.GA14522@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050304150129.GF2839@cygbert.vinschen.de> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00055.txt.bz2 On Fri, Mar 04, 2005 at 04:01:29PM +0100, Corinna Vinschen wrote: > On Mar 4 09:14, Daniel Jacobowitz wrote: > > On Fri, Mar 04, 2005 at 10:46:05AM +0100, Corinna Vinschen wrote: > > > I'm sorry, but the reason for getting rid of linetable-aware code is > > > somewhat beyond me. > > > > Because _there is nothing architecture specific about what you are > > doing_. Therefore, most likely, it is either right for all platforms > > or wrong for this one. I want to understand which. If it's right for > > all platforms, I'd like it to live in common code so that we can > > maintain it for all platforms. > > The platform specific part is to call iq2000_scan_prologue if the > line number information is bogus. > > > > I'll happily do something else, as far as it's > > > available and works, but using skip_prologue_using_sal is really no > > > option here. > > > > Why? Is it the same problem Kevin described? As I wrote, I have > > successfully used this function on other architectures. > > I haven't exactly analyzed the situation so far, but using > skip_prologue_using_sal results in three more FAILs in the testsuite: > > FAIL: gdb.base/break.exp: breakpoint small function, optimized file > FAIL: gdb.base/break.exp: run until breakpoint set at small function, optimized file > FAIL: gdb.base/nodebug.exp: running to inner in runto > > All three cases don't look like simple coincidence. In all three cases > we suffer from either optimized code or unavailable debug information. > The target specific "knowledge", which is represented by the call to > iq2000_scan_prologue helps to master this situation. Could you try the attached patch, which explains what I meant? 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. 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 other is as a limit for prologue scanners. IMO, what you need in iq2000_scan_prologue is not line table data at all, but a list of instructions which can not be considered part of the prologue. Basically that is calls and branches, and a check that you only record a register save the first time you see the register being saved. Going too far here is not a major problem; after the patch below, I think the call in iq2000_skip_prologue is basically redundant. Returning FUNC_ADDR would work just about as well, since if we have no line data, we probably have no symbolic argument information either. -- Daniel Jacobowitz CodeSourcery, LLC Index: src/gdb/iq2000-tdep.c =================================================================== --- src.orig/gdb/iq2000-tdep.c 2005-03-04 16:05:39.000000000 -0500 +++ src/gdb/iq2000-tdep.c 2005-03-04 16:39:49.000000000 -0500 @@ -335,20 +335,17 @@ iq2000_init_frame_cache (struct iq2000_f static CORE_ADDR iq2000_skip_prologue (CORE_ADDR pc) { - CORE_ADDR func_addr = 0 , func_end = 0; + CORE_ADDR func_addr = 0, func_end = 0, ret; + + ret = skip_prologue_using_sal (pc); + if (ret) + return max (ret, pc); if (find_pc_partial_function (pc, NULL, & func_addr, & func_end)) { - struct symtab_and_line sal; struct iq2000_frame_cache cache; - /* Found a function. */ - sal = find_pc_line (func_addr, 0); - if (sal.end && sal.end < func_end) - /* Found a line number, use it as end of prologue. */ - return sal.end; - - /* No useable line symbol. Use prologue parsing method. */ + /* Found a function. Use prologue parsing method. */ iq2000_init_frame_cache (&cache); return iq2000_scan_prologue (func_addr, func_end, NULL, &cache); }