> 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
