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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Dan Jacobowitz wrote:
> On Thu, Oct 21, 2010 at 05:50:51PM +0200, Ulrich Weigand wrote:
> > I understood the ARM standard to say that this was expected, because
> > for C or assembly routines, presence of an unwind entry is optional.
> > Is this not the case?
> 
> No, this is not the case.  The linker is supposed to fix it up:
[snip]
> If it's not doing that, we should figure out why - it can lead to
> crashes in libgcc, if the unwinder is invoked, rather than the correct
> failure to unwind.
> 
> I think 2.19 didn't do this but 2.20 did.

Hmm, the Ubuntu glibc image I'm using was built with 2.20.51.20100908-0ubuntu1
which should be recent enough ...

I'm re-running a glibc build from source to try and debug what the linker
is doing here.

> > Ah, I didn't see the readelf code (because I was looking at an old
> > checkout, I would appear).  I can add those personality routines as well
> > (however, these are nowhere used in the glibc I'm looking at).
> 
> Correct, they're only used with C cleanups or C++ exception throw/catch.

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?


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.

Note that even in a glibc built completely for Thumb, there still will
be some instances of the latter, e.g. the automatically generated
system call stubs (like the one for "kill") as well as certain
routines provided fully in assembler (like "vfork").  Unfortunately,
if these are called from Thumb code higher up the stack, the fact
that those routines clobber r7 (even as they themselves are ARM),
still breaks unwinding ...

Any thoughts how to fix this?  Should those calls also use an out-of-line
syscall helper?

Bye,
Ulrich

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