From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4690 invoked by alias); 23 Mar 2004 23:09:32 -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 4681 invoked from network); 23 Mar 2004 23:09:30 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 23 Mar 2004 23:09:30 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B5v1W-0006Hj-EX; Tue, 23 Mar 2004 18:09:30 -0500 Date: Tue, 23 Mar 2004 23:09:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] signal trampoline frames Message-ID: <20040323230930.GA23960@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <405E5A09.2050803@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <405E5A09.2050803@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00544.txt.bz2 On Sun, Mar 21, 2004 at 10:14:17PM -0500, Andrew Cagney wrote: > Hello, > > This adds "tramp-frame.[hc]" as a generic signal trampoline frame > unwinder. The client architectures, per the revised change to > ppcnbsd-tdep.c (it superseeds my original), just needs to provide the > signal trampoline instruction sequence and a method to initialize the > trad_frame_cache. > > Thoughts, I'll look to commit the tramp-frame parts in a few days. Some minor comments. > +static CORE_ADDR > +tramp_frame_start (CORE_ADDR pc, const struct tramp_frame *tramp) > +{ > + int ti; > + /* Search through the trampoline for one that matches the > + instruction sequence around PC. */ > + for (ti = 0; tramp->insn[ti] != 0; ti++) > + { > + CORE_ADDR func = pc - tramp->insn_size * ti; > + int i; > + for (i = 0; 1; i++) > + { > + bfd_byte buf[sizeof (LONGEST)]; > + CORE_ADDR insn; tramp->insn is a ULONGEST. Both of these should probably be ULONGEST also. > + if (tramp->insn[i] == 0) > + return func; So zeros in tramp->insn mark the end of the sequence? Should document that, zeros are valid instructions and some bizarre architecture might use one as a syscall trap. > + /* If the function has a valid symbol name, it isn't a > + trampoline. */ > + find_pc_partial_function (pc, &name, NULL, NULL); > + if (name != NULL) > + return 0; > + /* If the function lives in a valid section (even without a starting > + point) it isn't a trampoline. */ > + if (find_pc_section (pc) != NULL) > + return 0; I believe the first check is redundant to the second check; can we have names without sections? I may be wrong about this, remembering the problem on IRIX with absolute sections. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer