Re: [Libunwind-devel] libunwind ARM port

[Daniel Jacobowitz]

On Wed, Jan 02, 2008 at 10:20:50AM -0700, David Mosberger-Tang wrote:
> On 1/2/08, Daniel Jacobowitz <address@hidden> wrote:
> > And it breaks exceptions
> > completely for ARM, since the ARM libgcc_s unwinder uses the same API
> > but a different kind of compact unwind tables, not supported by
> > libunwind.  The standard .eh_frame sections are not present.
> 
> Is the format of these "compact unwind tables" described somewhere?
> It would be nice if libunwind would work at least as well or better
> than the libgcc_s unwinder, so if it's reasonably possible, it would
> be nice to add support for these compact tables.

Yes and no.

One major difference between the DWARF eh_frame scheme and the ARM
scheme is who parses the unwind tables.  In the eh_frame scheme,
the generic unwinder parses the tables; during exception handling,
it may dispatch to a personality routine afterwards.  In the ARM
scheme, the personality routine parses the tables.  If you can't call
the personality routine, you can't unwind.  And unwinding is normally
disruptive.  There's GNU extensions equivalent to _Unwind_ForcedUnwind
(CodeSourcery did this a while ago) and _Unwind_Backtrace (Andrew
Haley's work, though I do not know if it was merged to GCC yet or not).

There are standard formats for the tables, and standard ABI-defined
personality routines to parse the standard formats.  GNU tools only
produce the standard formats, but there's no obligation on third-party
tools to do so.  The GNU implementations of the standard routines
support forced unwinding and possibly backtracing; other runtimes,
like ARM's, may not.

So libunwind could be taught to handle the standard table formats, but
the full generality may be impractical.  In practice, handling the
standard formats would be useful.  It might be hard to replace
the libgcc unwinder this way, though.

Also there's a problem that we've been meaning to work around in the
GNU linker - you can't reliably tell from the tables where the end of
a region is.  So if one function has unwind info and the next one does
not, backtraces can go astray if you try to pass through the next
function.  This is a consequence of the design, which focused on
space efficiency and language exception handling only.

-- 
Daniel Jacobowitz
CodeSourcery