ARM signal trampolines

[Daniel Jacobowitz]

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