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]

ARM signal trampolines


I recently had a situation where I needed to attach to a program, and
examine a backtrace from a thread which was currently handling a
signal.? I know GDB has infrastructure in place for dealing with the
stack trampolines that get put in place during a signal emission, but
it didn't appear to be working--it hit the frame with the trampoline
and basically gave up.? In trying to track down why this wasn't
working, I ran into what I think are two separate problems.? I was
wondering if someone more knowledgeable in this code can confirm that
I'm understanding this correctly.

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

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.

Are these assessments correct?? If they are, I guess I don't
understand how this ever worked.? The first two are fairly trivial
problems, and I'd be happy to provide patches.  However, if the latter
is true, it doesn't seem like it's even going to be possible to do
this.? Does anybody have any thoughts on what's supposed to be going
on here?

Thanks,
Matt


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