ARM Linux EABI: unwinding through a segfault handler

[Paul Brook]

> On 10/27/2011 02:15 AM, Paul Brook wrote:
> >>>> So, suggestions welcome.  Is there a nice way to detect a signal
> >>>> frame?
> > 
> > That just makes me ask why are you're trying to detect a signal frame in
> > the first place?
> 
> Because I need backtrace() to work when called from a signal handler.

You've missed several logic step there :-)  On ARM the frame unwinding is 
performed by the personality routine.  The unwinding library has no business 
poking its nose in.
 
> > Short story is that the standard EABI unwinding opcodes can't describe a
> > signal frame accurately.  Especially if we don't know (when building
> > glibc) whether the application will be using VFP.
> > 
> > The good news is that The EABI unwinding tables delegate all interesting
> > behavior to the personality routine (c.f. DWARF unwinding where the frame
> > description is parsed by libunwind).  In order to accurately unwind
> > signal frames you need to have the sa_restorer functions reference a
> > custom personality routine that does the unwinding.
> > 
> > If something is specifying a non-default sa_restorer, then you loose.
> > Don't Do That :-)
> > 
> > While Richard is correct that the ARM EABI only requires unwinding
> > information at call sites, in practice as long as you use and accept the
> > limitations imposed by -fnon-call-exceptions, and ignore stack
> > overflows, it should be sufficient.
> 
> Sure, but without the fix I provided it doesn't work.  The problem is
> that the return address points to the faulting instruction, not the
> following instruction.  In the generic unwinder code, the boolean
> ip_before_insn is set to cope with this.  The ARM unwinder does not
> set this, so the backtrace does not work.

IMO you're fixing the wrong problem.  Instead you should advance the IP when 
unwinding the frame.  Given the unwinding tables for sa_restorer are already 
borken you may as well fix both at once :-)

Paul