This is the mail archive of the
mailing list for the GCC project.
Re: ARM Linux EABI: unwinding through a segfault handler
- From: Paul Brook <paul at codesourcery dot com>
- To: gcc at gcc dot gnu dot org
- Cc: Daniel Jacobowitz <drow at false dot org>, Ken Werner <ken dot werner at linaro dot org>, Andrew Haley <aph at redhat dot com>, ramana dot radhakrishnan at arm dot com, richard dot earnshaw at arm dot com
- Date: Thu, 27 Oct 2011 02:15:08 +0100
- Subject: Re: ARM Linux EABI: unwinding through a segfault handler
- References: <4E563F58.email@example.com> <4E5BADCC.firstname.lastname@example.org> <CAN9gPaHOOuNmNwN04jx5CkFNwPUiwjn9R_1H=XLJ06T3fMnYKw@mail.gmail.com>
> >> 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
> > Libunwind also reads the IP to detect signal frames on ARM Linux:
> > http://git.savannah.gnu.org/gitweb/?p=libunwind.git;a=blob;f=src/arm/Gis_
> > signal_frame.c;hb=HEAD
> > I'd also be interested if there are better approaches to detect them. :)
> There aren't better ways - this is pretty much the standard for
> on-stack signal frames :-)
> I thought we used a handler in GLIBC that was properly annotated,
> nowadays, but I might be mistaken.
We do, but the annotation is fairly approximate.
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