From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8566 invoked by alias); 3 Mar 2004 20:41:44 -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 8559 invoked from network); 3 Mar 2004 20:41:43 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 3 Mar 2004 20:41:43 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9D0F02B92; Wed, 3 Mar 2004 15:41:38 -0500 (EST) Message-ID: <40464302.3060308@gnu.org> Date: Fri, 19 Mar 2004 00:09:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] trad-frame change References: <40460B28.3000504@gnu.org> <20040303164933.GB18032@nevyn.them.org> <4046252F.7020504@gnu.org> <20040303185319.GA19699@nevyn.them.org> <40463E1C.1060502@gnu.org> <20040303202954.GA29400@nevyn.them.org> In-Reply-To: <20040303202954.GA29400@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00058.txt.bz2 >>> 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. Like you said, theoretical - program for what is, not what might be, but what ever. >>>> >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. Not that cache, a new one, yes, someday. Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8566 invoked by alias); 3 Mar 2004 20:41:44 -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 8559 invoked from network); 3 Mar 2004 20:41:43 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 3 Mar 2004 20:41:43 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9D0F02B92; Wed, 3 Mar 2004 15:41:38 -0500 (EST) Message-ID: <40464302.3060308@gnu.org> Date: Wed, 03 Mar 2004 20:41:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [rfc] trad-frame change References: <40460B28.3000504@gnu.org> <20040303164933.GB18032@nevyn.them.org> <4046252F.7020504@gnu.org> <20040303185319.GA19699@nevyn.them.org> <40463E1C.1060502@gnu.org> <20040303202954.GA29400@nevyn.them.org> In-Reply-To: <20040303202954.GA29400@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00058.txt Message-ID: <20040303204100.xT1ZwNHWlUWSWMKqoR7kwqn0N8NgwUWNLTDt3gfYZYU@z> >>> 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. Like you said, theoretical - program for what is, not what might be, but what ever. >>>> >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. Not that cache, a new one, yes, someday. Andrew