This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [rfc/rfa] Use ARM exception tables as GDB unwinder
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: dan at codesourcery dot com (Daniel Jacobowitz)
- Cc: gdb-patches at sourceware dot org, rearnsha at arm dot com, matthew dot gretton-dann at arm dot com
- Date: Thu, 21 Oct 2010 22:29:32 +0200 (CEST)
- Subject: Re: [rfc/rfa] Use ARM exception tables as GDB unwinder
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