This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: ARM signal trampolines
On Fri, Jan 15, 2010 at 04:46:52PM -0600, Matt Fischer wrote:
> 1.? When delivering a signal, ARM Linux constructs a stack frame with
> a return address pointing to a trampoline in the vector table
> (0xffff0500-0xffff0514), which in turn issues a syscall back into the
> kernel.? GDB has unwinders for this, but it looks like they have a
> couple problems.
> ?? a.? There is no unwinder for a return to Thumb code
> (SWI_THUMB_SIGRETURN in arch/arm/kernel/signal.c.)
Looks that way. This code doesn't matter though... GLIBC always sets
SA_RESTORER. What C library are you using that could trigger this
at all?
> ?? b.? The normal EABI unwinder (arm_eabi_linux_sigreturn_tramp_frame)
> seems to be incorrect as well.? It expects to see 0xe3a07077
> 0xef000000 (ARM_SET_R7_SIGRETURN followed by ARM_EABI_SYSCALL.)
> However the kernel's vector table tries to be cute, and overlaps the
> EABI return sequence with the OABI syscall instruction, meaning that
> what's actually in the vector table is 0xe3a07077 0xef900077.
> Therefore, it doesn't match correctly.
None of this code is for the vector area trampolines which are brand
new. Just a few months old, I believe. It is for the SA_RESTORER
functions in glibc.
> 2.? A bigger problem, though, is that GDB can't seem to read the
> vector table area at all.? Any attempt to examine that memory area
> results in garbage values.? Indeed, I can't even seem to get ptrace()
> to read that memory area in any process--any attempt to do so just
> returns -1.? This makes it seem as though the kernel just doesn't let
> you read that region via ptrace() at all.
That's correct. There's a workaround for single-stepping through the
atomic operations on the same vector page, for this reason. The
correct solution depends on whether the signal trampolines are at an
ABI-fixed address. If they are, we could hardcode them. Otherwise,
someone has to stop putting off making the page ptrace readable.
--
Daniel Jacobowitz
CodeSourcery