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

["Ulrich Weigand" <uweigand@de.ibm.com>]

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

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com