From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3951 invoked by alias); 3 Mar 2004 00:18:58 -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 3939 invoked from network); 3 Mar 2004 00:18:56 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 3 Mar 2004 00:18:56 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 227C12B92; Tue, 2 Mar 2004 19:18:52 -0500 (EST) Message-ID: <4045246C.5000702@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: Jason Thorpe Cc: Mark Kettenis , drow@false.org, gdb-patches@sources.redhat.com Subject: Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder References: <40428C58.1020506@gnu.org> <20040301012656.GA16265@nevyn.them.org> <404292D7.9040100@gnu.org> <20040301024711.GA27915@nevyn.them.org> <200403010933.i219X4v3002550@elgar.kettenis.dyndns.org> <6FDEB6FE-6CA1-11D8-BE41-000A957650EC@wasabisystems.com> In-Reply-To: <6FDEB6FE-6CA1-11D8-BE41-000A957650EC@wasabisystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00036.txt.bz2 > > On Mar 1, 2004, at 1:33 AM, Mark Kettenis wrote: > >> The problem is that the location of the signal trampoline depends on >> the VM layout, which can be changed. And on OpenBSD (which is very >> similar to NetBSD in many respects) the signal trampoline is mapped at >> a random location. So checking for the address isn't the most robust >> way. That's why NetBSD/i386 doesn't do this anymore, but instead >> looks for a specific instruction sequence (the instruction sequence >> for the sigreturn(2) system call). > > > Yes, other NetBSD targets do this as well, Alpha and MIPS, for example. > >> NetBSD is moving away from using kernel-provided signal trampolines. >> NetBSD 2.0 will use signal trampolines provided by libc. These >> tramplones can be recognized by their name: they start with >> __sigtramp. See nbsd-tdep.c:nbsd_pc_in_sigtramp() and its usage in >> amd64nbsd-tdep.c. > > > Right. They've been provided by libc for quite some time in -current, and 2.0 will ship with them when it ships. So something like: if (have symbol) { return (symbol matches __sigtramp.*); } else { return (mem[pc] == magic && mem[pc+1] == magic && ...); } Is it possible to add an extra guard to the else clause so that memory is only examined when there's a reasonable likelyhood of it being a sigtramp? Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3951 invoked by alias); 3 Mar 2004 00:18:58 -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 3939 invoked from network); 3 Mar 2004 00:18:56 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 3 Mar 2004 00:18:56 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 227C12B92; Tue, 2 Mar 2004 19:18:52 -0500 (EST) Message-ID: <4045246C.5000702@gnu.org> Date: Wed, 03 Mar 2004 00:18: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: Jason Thorpe Cc: Mark Kettenis , drow@false.org, gdb-patches@sources.redhat.com Subject: Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder References: <40428C58.1020506@gnu.org> <20040301012656.GA16265@nevyn.them.org> <404292D7.9040100@gnu.org> <20040301024711.GA27915@nevyn.them.org> <200403010933.i219X4v3002550@elgar.kettenis.dyndns.org> <6FDEB6FE-6CA1-11D8-BE41-000A957650EC@wasabisystems.com> In-Reply-To: <6FDEB6FE-6CA1-11D8-BE41-000A957650EC@wasabisystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03.o/txt/msg00036.txt Message-ID: <20040303001800.Il-6s8uzdMjeTaVN8qYQBFGnw4HarSILDri6Q1j_zJ4@z> > > On Mar 1, 2004, at 1:33 AM, Mark Kettenis wrote: > >> The problem is that the location of the signal trampoline depends on >> the VM layout, which can be changed. And on OpenBSD (which is very >> similar to NetBSD in many respects) the signal trampoline is mapped at >> a random location. So checking for the address isn't the most robust >> way. That's why NetBSD/i386 doesn't do this anymore, but instead >> looks for a specific instruction sequence (the instruction sequence >> for the sigreturn(2) system call). > > > Yes, other NetBSD targets do this as well, Alpha and MIPS, for example. > >> NetBSD is moving away from using kernel-provided signal trampolines. >> NetBSD 2.0 will use signal trampolines provided by libc. These >> tramplones can be recognized by their name: they start with >> __sigtramp. See nbsd-tdep.c:nbsd_pc_in_sigtramp() and its usage in >> amd64nbsd-tdep.c. > > > Right. They've been provided by libc for quite some time in -current, and 2.0 will ship with them when it ships. So something like: if (have symbol) { return (symbol matches __sigtramp.*); } else { return (mem[pc] == magic && mem[pc+1] == magic && ...); } Is it possible to add an extra guard to the else clause so that memory is only examined when there's a reasonable likelyhood of it being a sigtramp? Andrew