How to benefit from asynchronous unwind tables?
David Daney
ddaney@caviumnetworks.com
Sat Oct 17 02:02:00 GMT 2009
Ewgenij Gawrilow wrote:
> 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?
>
The problem isn't the signal handler frames. The unwinder can unwind
through them all.
The problem is that you must have accurate unwind tables in 100% of your
code (including libc, ld.so, and all other possible libraries that you
might be calling) if you want to be able to unwind from asynchronous
signals.
With SIGFPE and SIGSEGV, the compiler knows exactly where they might be
generated and only needs accurate unwind tables at those locations.
David Daney
More information about the Gcc-help
mailing list