This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa:NetBSD/ppc] Implement signal trampoline unwinder



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.

Jason, am I correct to assume that the second SC here:


(gdb) x/10i $lr
0x7fffefdc:     addi    r3,r1,24
0x7fffefe0:     li      r0,295
0x7fffefe4:     sc
0x7fffefe8:     li      r0,1
0x7fffefec:     sc
0x7fffeff0:     .long 0x7fffe56c

isn't part of the sigtramp?

Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]