From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4995 invoked by alias); 3 Mar 2004 20:29:55 -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 4988 invoked from network); 3 Mar 2004 20:29:54 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 3 Mar 2004 20:29:54 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Ayd06-0007nR-Dt; Wed, 03 Mar 2004 15:29:54 -0500 Date: Wed, 03 Mar 2004 20:29:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] trad-frame change Message-ID: <20040303202954.GA29400@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <40460B28.3000504@gnu.org> <20040303164933.GB18032@nevyn.them.org> <4046252F.7020504@gnu.org> <20040303185319.GA19699@nevyn.them.org> <40463E1C.1060502@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40463E1C.1060502@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03.o/txt/msg00056.txt On Wed, Mar 03, 2004 at 03:20:44PM -0500, Andrew Cagney wrote: > >There are four kinds of signal frames on MIPS/Linux that we have to > >recognize: > > - o32 sigreturn > > - o32 rt_sigreturn > > - n32 rt_sigreturn > > - n64 rt_sigreturn > > > >They're all basically the same but the offsets differ. Kind could be > >moved out of the cache, I think, since it isn't used after the cache is > >filled. So I could use your new mechanism after all. > > So there are really two variants - o32sigreturn and rt_sigreturn (with > constants computed from the architecture vector)? I don't see much point in distinguishing them that way, honestly. The difference between o32 sigreturn and o32 rt_sigreturn is about the same as the difference between n32 and n64. Sure, you could put the constants in the architecture tdep vector... but why bother? And it may be silly, but there's nothing stopping a theoretical hand-written program from using a different ABI's sigreturn syscall. > >What would _really_ be nice would be a way to pass the kind from the > >sniffer (which really just calls PC_IN_SIGTRAMP) to the frame creation > >code... not have to read inferior memory to figure out which it is, > >twice. > > I'll think about that, I may need to change the unwinder object anyway. > > Just remember that it is the number of unique addresses accessed (0 vs 1 > vs 2 ...) and not the number of times each address is accessed that is > going to be important - multiple accesses to a single address can be > handled with a cache. We really should turn on that cache someday. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4995 invoked by alias); 3 Mar 2004 20:29:55 -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 4988 invoked from network); 3 Mar 2004 20:29:54 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 3 Mar 2004 20:29:54 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Ayd06-0007nR-Dt; Wed, 03 Mar 2004 15:29:54 -0500 Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] trad-frame change Message-ID: <20040303202954.GA29400@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <40460B28.3000504@gnu.org> <20040303164933.GB18032@nevyn.them.org> <4046252F.7020504@gnu.org> <20040303185319.GA19699@nevyn.them.org> <40463E1C.1060502@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40463E1C.1060502@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00056.txt.bz2 Message-ID: <20040319000900.OeWoMoBh8t-XE5mhE1KPVTywJTI83yM5NYxw75mip4c@z> On Wed, Mar 03, 2004 at 03:20:44PM -0500, Andrew Cagney wrote: > >There are four kinds of signal frames on MIPS/Linux that we have to > >recognize: > > - o32 sigreturn > > - o32 rt_sigreturn > > - n32 rt_sigreturn > > - n64 rt_sigreturn > > > >They're all basically the same but the offsets differ. Kind could be > >moved out of the cache, I think, since it isn't used after the cache is > >filled. So I could use your new mechanism after all. > > So there are really two variants - o32sigreturn and rt_sigreturn (with > constants computed from the architecture vector)? I don't see much point in distinguishing them that way, honestly. The difference between o32 sigreturn and o32 rt_sigreturn is about the same as the difference between n32 and n64. Sure, you could put the constants in the architecture tdep vector... but why bother? And it may be silly, but there's nothing stopping a theoretical hand-written program from using a different ABI's sigreturn syscall. > >What would _really_ be nice would be a way to pass the kind from the > >sniffer (which really just calls PC_IN_SIGTRAMP) to the frame creation > >code... not have to read inferior memory to figure out which it is, > >twice. > > I'll think about that, I may need to change the unwinder object anyway. > > Just remember that it is the number of unique addresses accessed (0 vs 1 > vs 2 ...) and not the number of times each address is accessed that is > going to be important - multiple accesses to a single address can be > handled with a cache. We really should turn on that cache someday. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer