How to benefit from asynchronous unwind tables?

[Ewgenij Gawrilow]

David Daney wrote:
> Ewgenij Gawrilow wrote:
>> Hello,
>>
>> is somebody out there who has consciously used the asynchronous unwind
>> tables?  The GCC documentation does not reveal much more about this
>> feature than the mere statement of its existence.
>>
>> What I eventually need is the possibility to catch certain signals and
>> unwind a part of the stack down to a certain frame in a mixed C / C++
>> program.
>>
>> A naive approach of throwing an exception from the signal handler does
>> not work, neither does a siglongjump from the handler unwind the stack
>> frames between it and the frame where sigsetjump was executed (although
>> some C++ ABI drafts suggested this behaviour).
>>
>> The main problem is probably the kernel-generated frame of the signal
>> handler, lying between the frame where unwinding starts and the catching
>> frame.  If I set up the signal handler to use the alternative stack,
>> this frame won't be an obstacle any more; but I didn't find any clue how
>> to tell the unwinding machinery (_Unwind_RaiseException and the
>> relatives) as it is implemented in libgcc, that it has to scan over a
>> different stack.
>>
> 
> libgcj (GCC's java runtime library) does exactly what you describe for
> synchronous signals (SIGSEGV, SIGFPE).  Throwing exceptions through such
> signal frames does work for both i386 and x86_64 (as well as many other
> architectures) on linux.  Unwinding from arbitrary asynchronous signals
> (SIGUSR1 etc.) is not supported.
> 
> The code that does it can be found in libjava/prims.cc
> 

Do you (or somebody else) know by chance what's the major difference between the signal handler
frames generated by SIGFPE and, say, SIGINT?  Is it documented anywhere?