This is the mail archive of the gdb@sourceware.org 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: ARM signal trampolines


On Mon, Jan 18, 2010 at 10:03 PM, Daniel Jacobowitz
<dan@codesourcery.com> wrote:
> On Mon, Jan 18, 2010 at 04:27:23PM -0600, Matt Fischer wrote:
>> > 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?
>
> I may be confused. ?I thought it previously copied code to the stack,
> and only recently started putting it on the vector page.
>
It looks like it also copies it to the stack, but as long as we're
running in 32-bit mode, it uses the vector page, so that it doesn't
need to do an i-cache flush on the stack (and to reduce the need for
an executable stack.)  This looks to have been added around 2005.
Glibc appears to set a restorer for exactly the same reason, but it
predates this kernel logic by several years, so I imagine it was added
to work around this problem back in the days of ARM2 or something,
before the kernel had the snazzy high memory page.  It looks like
there is probably not a need for it anymore, since the kernel now does
exactly the same thing anyway.

>> 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.
>
> Yes, that will be easy and should work.
>
I've implemented this and it seems to work great.  Thanks for all your help.

--Matt


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