From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23093 invoked by alias); 4 Mar 2005 09:46: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 22963 invoked from network); 4 Mar 2005 09:46:17 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 4 Mar 2005 09:46:17 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j249kH4C025206 for ; Fri, 4 Mar 2005 04:46:17 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j249kGK24362 for ; Fri, 4 Mar 2005 04:46:16 -0500 Received: from cygbert.vinschen.de (vpn50-12.rdu.redhat.com [172.16.50.12]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j249kC5s013827 for ; Fri, 4 Mar 2005 04:46:14 -0500 Received: by cygbert.vinschen.de (Postfix, from userid 500) id 2298C57D6E; Fri, 4 Mar 2005 10:46:05 +0100 (CET) Date: Fri, 04 Mar 2005 09:46:00 -0000 From: Corinna Vinschen To: gdb-patches@sources.redhat.com Subject: Re: [RFA] New GDB target iq2000 Message-ID: <20050304094605.GU2839@cygbert.vinschen.de> Reply-To: gdb-patches@sources.redhat.com Mail-Followup-To: gdb-patches@sources.redhat.com References: <20050222114141.GA18314@cygbert.vinschen.de> <20050303173443.GD18681@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050303173443.GD18681@nevyn.them.org> User-Agent: Mutt/1.4.2i X-SW-Source: 2005-03/txt/msg00041.txt.bz2 On Mar 3 12:34, Daniel Jacobowitz wrote: > On Tue, Feb 22, 2005 at 12:41:41PM +0100, Corinna Vinschen wrote: > > As a result, the dwarf2 frame sniffer has a problem with code generated > > by GCC's older than two days. This is no problem for the iq2000 frame > > sniffer implemented in iq2000-tdep.c, but as usual, the iq2000 frame > > sniffer is appended after the dwarf2 frame sniffer: > > > > frame_unwind_append_sniffer (gdbarch, dwarf2_frame_sniffer); > > frame_unwind_append_sniffer (gdbarch, iq2000_frame_sniffer); > > > > Would that be a good reason to disable the dwarf2 frame sniffer for now? > > Or shall I leave that as is? > > It's up to you; I think leaving it as is and writing off the problem as > a broken compiler will probably be good enough for the iq2000 userbase. > If it isn't, we can come back to the problem later. Sounds like a plan to me. > It looks good to me, but I have one concern. You've got > find_last_line_symbol: > > > +/* Function: find_last_line_symbol > > + > > + Given an address range, first find a line symbol corresponding to > > + the starting address. Then find the last line symbol within the > > + range that has a line number less than or equal to the first line. > > + > > + For optimized code with code motion, this finds the last address > > + for the lowest-numbered line within the address range. */ What's your exact concern with this function? It's just used inside of the iq2000 prologue scanner to decide if the scanning loop should break or continue. > And you've got this too: > > > +static CORE_ADDR > > +iq2000_skip_prologue (CORE_ADDR pc) > > +{ > > + CORE_ADDR func_addr = 0 , func_end = 0; > > + > > + 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. */ > > + iq2000_init_frame_cache (&cache); > > + return iq2000_scan_prologue (func_addr, func_end, NULL, &cache); > > + } > > + > > + /* No function symbol -- just return the PC. */ > > + return (CORE_ADDR) pc; > > +} > > I'm trying to cut down on the proliferation of linetable-aware code in > tdep files. We've already got skip_prologue_using_sal, which is > similar but not quite the same. Will that work for iq2000? Failing > that, should the new method be used on other targets? There's nothing > iq2000 specific about it. Except for calling iq2000_scan_prologue, a function which is entirely internal to the iq2000 code and not available through the gdbarch framework. I'm sorry, but the reason for getting rid of linetable-aware code is somewhat beyond me. 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. Any chance I can apply the code, after removing the set_gdbarch_decr_pc_after_break call? Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat, Inc.