From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29855 invoked by alias); 3 Mar 2004 20:20: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 29848 invoked from network); 3 Mar 2004 20:20:48 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 3 Mar 2004 20:20:48 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6C1FE2B92; Wed, 3 Mar 2004 15:20:44 -0500 (EST) Message-ID: <40463E1C.1060502@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> In-Reply-To: <20040303185319.GA19699@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00055.txt.bz2 > 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)? > 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. Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29855 invoked by alias); 3 Mar 2004 20:20: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 29848 invoked from network); 3 Mar 2004 20:20:48 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 3 Mar 2004 20:20:48 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6C1FE2B92; Wed, 3 Mar 2004 15:20:44 -0500 (EST) Message-ID: <40463E1C.1060502@gnu.org> Date: Wed, 03 Mar 2004 20:20: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> In-Reply-To: <20040303185319.GA19699@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00055.txt Message-ID: <20040303202000.6vb9F1U2ulzh-lQ4YaNrPSddjHtBjR8d511QFIWtL38@z> > 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)? > 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. Andrew