Re: ARM signal trampolines

[Matt Fischer <mattfischer84@gmail.com>]

On Fri, Jan 15, 2010 at 5:17 PM, Daniel Jacobowitz <dan@codesourcery.com> wrote:

> 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?

I'm working on an Android system.  Bionic doesn't seem to bother with
SA_RESTORER--it just wires sigaction() straight up to the syscall, so
unless you specify your own, the kernel sets up the stack frame with a
return address pointing to the trampolines on the vector page.

> 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.

I guess I'm confused--the code I'm looking at appears to have been in
the kernel since about 2.6.13--it's the vector of return codes called
sigreturn_codes[] in arch/arm/kernel/signal.c, which gets copied to
the vector page by trap_init() in arch/arm/kernel/traps.c.  Is there
some other change which has been made to this mechanism in more recent
kernels?

>> 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.

Given what you've said, the easiest thing to do for my purposes is
probably just to patch Bionic to use SA_RESTORER.  Then I can just
ensure the trampoline is constructed to match what's already in there
for glibc, and things should all work out.  I don't know if I could
get it accepted upstream or not, but it should at least allow my local
testing to work out.

Long term, though, it would certainly be nice if gdb could see the
vector page--I've run into a couple situations where I've needed to
see what was in there, and gdb wasn't able to help.  It seems like the
kernel patch to do this wouldn't be overly complicated--is there some
reason that this isn't a desirable feature, or is it just that
nobody's had a pressing enough need for it so far?

--Matt