[patch 3/3, nios2] fixes for new implementation of signal handler trampolines
Sandra Loosemore
sandra@codesourcery.com
Thu Apr 23 19:01:00 GMT 2015
Earlier versions of the nios2 kernel used to allocate code for signal
handler trampolines on the stack, but when the port was accepted
upstream it was changed to instead put the trampoline at a fixed address
in low memory (0x1044).
Moving the code off the stack changed the layout of the stack frame, so
the first part of this fix involves updating the offset to the register
save area. This is not an exported interface from the kernel; I noticed
e.g. the existing aarch64 gdb support includes a huge block of comments
explaining the kernel's signal handler stack frame layout but ultimately
also relies on using magic numbers to access the register save area. I
used a somewhat smaller block of comments for nios2 but I think now it
is clear where the magic numbers come from and what kernel code this
corresponds to.
The second problem is that the trampoline is not writable by user
processes so GDB cannot set software breakpoints there. I've tried to
deal with that in the single-step hook by having it effectively step
over the trampoline by setting the breakpoint on its return address, but
for operations like "finish" or "advance" that use the stack unwinder to
get the location to set the breakpoint, it seems like there is nothing
to do but kfail the tests.
OK to commit?
-Sandra
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb-sigtramp.log
Type: text/x-log
Size: 590 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20150423/3a34b61c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdb-sigtramp.patch
Type: text/x-patch
Size: 6554 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20150423/3a34b61c/attachment-0001.bin>
More information about the Gdb-patches
mailing list