From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 441 invoked by alias); 1 Mar 2004 09:34:06 -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 434 invoked from network); 1 Mar 2004 09:34:04 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.115.144) by sources.redhat.com with SMTP; 1 Mar 2004 09:34:04 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i219XCBP001919; Mon, 1 Mar 2004 10:33:12 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i219XCOm002553; Mon, 1 Mar 2004 10:33:12 +0100 (CET) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i219X4v3002550; Mon, 1 Mar 2004 10:33:04 +0100 (CET) Date: Fri, 19 Mar 2004 00:09:00 -0000 Message-ID: <200403010933.i219X4v3002550@elgar.kettenis.dyndns.org> From: Mark Kettenis To: drow@false.org CC: cagney@gnu.org, thorpej@wasabisystems.com, gdb-patches@sources.redhat.com In-reply-to: <20040301024711.GA27915@nevyn.them.org> (message from Daniel Jacobowitz on Sun, 29 Feb 2004 21:47:11 -0500) 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> X-SW-Source: 2004-03/txt/msg00008.txt.bz2 Message-ID: <20040319000900.a4ZVE7KMtalx6n_t7x4FxJKn6bBW_wz2T3Nanpk6Kjc@z> Date: Sun, 29 Feb 2004 21:47:11 -0500 From: Daniel Jacobowitz On Sun, Feb 29, 2004 at 08:33:11PM -0500, Andrew Cagney wrote: > >On Sun, Feb 29, 2004 at 08:05:28PM -0500, Andrew Cagney wrote: > > > >>>It appears to work (but doesn't have much effect without an rs6000 > >>>unwinder). > >>> > >>>One question (and to follow up my earlier post) is there a better way of > >>>doing this: > >>> > >>>+ if (frame_pc_unwind (next_frame) > 0x7f000000) > >>>+ /* Assume anything that is vaguely on the stack is a signal > >>>+ trampoline. */ > >>>+ return &ppcnbsd_sigtramp_unwind; > >>> > >>>ok?, eventually for 6.1? > > > > > >For other targets, we grub in the code for the sigtramp instruction > >sequence. I'm betting it's fixed for NetBSD too? ppc_linux_in_sigtramp > >does this. > > That's potentially expensive - there should also be a predicate like the > above before the stack is read checked. Then you risk both sigaltstack and thread support. Thread stacks can end up literally anywhere - and do! Not really. While the signal trampoline appears to be on the stack, it really is a specially mapped area just at the end of the userspace VM range. This mapping appears at the same location in all the threads, regardless whether you use sigaltstack or not. 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). If you're going to check the instruction sequence, you can optimize things by only doing so if NAME is NULL. It might be possible to compare to the current stack pointer, if you're convinced the sigreturn sequence will remain on the stack. I don't know anything about NetBSD - for e.g. i386 GNU/Linux, this isn't necessarily true, but that's handled specially. 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. Mark