Re: [rfc/rfa] Use ARM exception tables as GDB unwinder

Ulrich Weigand
2010-10-21T20:29:43Z

Dan Jacobowitz wrote:
> On Thu, Oct 21, 2010 at 08:26:09PM +0200, Ulrich Weigand wrote:
> > One issue with this just occurred to me: comparing personality routines
> > by *name* relies on symbol information being present. Since we're doing
> > the whole ARM unwinder support primarily to better cope with the case
> > where symbol information is absent, this may be counter-productive ...
> >
> > Is there some other way to recognize those particular unwinders?
>
> Yes, it's true that this requires names. Fortunately, in the usual
> case they are in the dynamic symbol table. So, I think you'll have
> the names - or do we not see dynamic symbols here?

Hmm, I was confused by readelf apparently being unable to resolve
them in the case of libstdc++:

Unwind table index '.ARM.exidx' at offset 0x95768 contains 1433 entries:

0x44704: 0x1 [cantunwind]

0x4478c: 0x80aab0b0
Compact model 0
0xaa pop {r4, r5, r6r14}
0xb0 finish
0xb0 finish

0x44804: 0x1 [cantunwind]

0x44938: @0x8fec0
Personality routine: 0x43264

0x44990: @0x8fedc
Personality routine: 0x43264

0x44b00: 0x1 [cantunwind]

But in fact 0x43264 is the address of the PLT entry pointing to this
jump slot:
000a4480 000d7516 R_ARM_JUMP_SLOT 00084e25 __gxx_personality_v0

So we should certainly be able to resolve that in GDB.

> > Another, related topic: Running the GDB testsuite on a system without
> > debug/symbol info, I'm still seeing failures in unwinding from interrupted
> > system calls. This is because the assembler code to do the syscall
> > clobbers r7 without generating appropriate unwind records, and thus
> > unwinding fails somewhere higher up the stack.
> >
> > Now, this is exactly the problem you fixed by moving the actual syscall
> > into a separate routine __libc_do_syscall. However, this routine is
> > only called from C code built for -mthumb. C code built for -marm,
> > as well as code originally in (ARM) assembler, will continue to use
> > inline sequences clobbering r7.
>
> This should work... the problem with r7 was that it's the hard frame
> pointer for Thumb (even Thumb-2 - although it shouldn't be, most
> likely, it's a wasteful choice). So we couldn't mark it as
> clobbered. Does GCC not mark r7 as saved on the stack for the ARM
> code? It should know perfectly well that r7 is not unchanged.

Right, for C code there should be no problem. The problems I've been
seeing all come from *assembler* source files using the DO_CALL macro.
This gets CFI correct, but doesn't create any unwind records ...