This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder
Date: Sun, 29 Feb 2004 21:47:11 -0500
From: Daniel Jacobowitz <drow@false.org>
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