This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM Linux EABI: unwinding through a segfault handler

On 10/27/2011 12:53 PM, Paul Brook wrote:
>> 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.

OK, so I need a way to fix the personality routine.

>>> 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 :-)

I'm trying to understand what you mean, but your comments are rather obscure.
Which file do you think I should change?  Just tell me where to look and
I'll do it.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]