From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 979 invoked by alias); 24 Mar 2004 17:15:49 -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 813 invoked from network); 24 Mar 2004 17:15:47 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 24 Mar 2004 17:15:47 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B6Byl-0004Zl-3u; Wed, 24 Mar 2004 12:15:47 -0500 Date: Wed, 24 Mar 2004 17:15:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [patch/rfc] signal trampoline frames Message-ID: <20040324171547.GA17526@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <405E5A09.2050803@gnu.org> <20040323230930.GA23960@nevyn.them.org> <4060D025.6070601@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4060D025.6070601@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00566.txt.bz2 On Tue, Mar 23, 2004 at 07:02:45PM -0500, Andrew Cagney wrote: > see attached? > > > > >>>+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. > > changed to ->insn[0] I was more concerned about the CORE_ADDR. > >>>+ 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. > > Added TRAMP_SENTINEL_INSN, it _isn't_ zero. The comment in the attached still says it's zero. Zero and -1 are just about equally likely/unlikely, so I don't think it matters what the value is; I like having TRAMP_SENTINEL_INSN though. > I don't know. Doesn't much matter then. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer