> >> 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? > > 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 sufficient. Paul
