How to benefit from asynchronous unwind tables?

[David Daney]

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.
> 
> I'd deeply appreciate any helpful advice and tips.  The solution needn't
> be universally portable; I'll be overly glad to get it running under
> Linux on i386 and x86_64, and in the further future, if possible, under
> MacOS.
> 

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



David Daney