Re: Fw: Re: Java interpreter on ARM GNU/Linux
On Fri, Jul 13, 2007 at 11:08:15AM +0100, Andrew Haley wrote:
> > > I can work around some of the failures, but I can't really be
> > > bothered: the real fix for this is EABI.
> > Unfortunately, the EABI won't fix this either. In its native form it
> > supported neither forced unwinding nor _Unwind_Backtrace; we added
> > forced unwinding for the benefit of NPTL (though we're still talking
> > to ARM intermittently about its semantics). But no one's tried to
> > make _Unwind_Backtrace work yet, and it's not clear how to. To me
> > anyway.
> Interesting. Presumably there is enough information in the unwinder
> data to do it? If it's technically impossible to do a simple
> backtrace then I have to wonder what the point of the EABI is.
The data is there, but it's not structured the right way. In
.eh_frame unwinding, there's a standard format to define saved
registers and an augmentation to define the language-specific data and
the personality routine which understands that language-specific data.
In ARM EABI unwinding, the personality routine is responsible for
reading the saved register data as well as the language specific
data. So the core unwinder (_Unwind_* in libgcc) is limited in what
it can do by the flags accepted by the personality routines.
There are several standard formats defined by the EHABI. GCC only
ever uses those. But we might not have our own implementations of the
personality routines, so we can't ABI-conformantly pass them invalid
flags. We play a little loose with this for forced unwinding and let
ourselves sleep at night since we proposed standardization language
for them to ARM :-)
However, for the standard table formats and personality routines, we
could arrange to do backtraces anyway. It should be just a matter of
a day's work or so and a little more code in the unwinder, and it
would work with all GCC-compiled code with unwind info.