This is the mail archive of the gcc@gcc.gnu.org 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.

Andrew.


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