This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ARM Linux EABI: unwinding through a segfault handler
- From: Andrew Haley <aph at redhat dot com>
- To: Paul Brook <paul at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, Daniel Jacobowitz <drow at false dot org>, Ken Werner <ken dot werner at linaro dot org>, ramana dot radhakrishnan at arm dot com, richard dot earnshaw at arm dot com
- Date: Thu, 27 Oct 2011 12:58:00 +0100
- Subject: Re: ARM Linux EABI: unwinding through a segfault handler
- References: <4E563F58.2060006@redhat.com> <201110270215.09012.paul@codesourcery.com> <4EA918D0.3000009@redhat.com> <201110271253.14077.paul@codesourcery.com>
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.