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?
