This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Unix Signals as OS Exceptions in C++
- From: Andrew Haley <aph at redhat dot com>
- To: "Steven T. Hatton" <hattons at globalsymmetry dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 13 Sep 2004 10:54:52 +0100
- Subject: Unix Signals as OS Exceptions in C++
- References: <200409112057.47137.hattons@globalsymmetry.com>
Steven T. Hatton writes:
> The article on the following link discusses a mechanism to handle exceptions
> generated by the Microsoft Windows OS.
>
> http://www.codeproject.org/cpp/exceptionhandler.asp#xx515459xx
>
> Since the counterpart to the Windows Structured Exception Handling is
> (probably) Unix signaling, it seems a comperable mechanism on Unix and
> Unix-like OS's would need to translate signals to exceptions. This seems to
> me to be the domain of GCC.
>
> I've never heard of such a feature. Perhaps this is just a question of RTFM.
> If so, please let me know. If not, then let me suggest the gcj may provide
> an example of how to implement this support for C++ exception handling.
A gcj guy speaks...
You must distinguish between synchronous and asynchronous signals.
We can throw exceptions from signals in Java because we know that only
two synchronous exceptions are relevant: DivideOverflow and
NullPointer, which usually map directly onto FPE and SEGV. We can do
this only on systems with full stack unwinder support -- just Darwin
and GNU/Linux at the present time. This requires considerable work in
the compiler itself, because every instruction that may trap has an
edge in the control flow graph to reachable exception handlers.
(Consider what would be required to make this work with asynchronous
signals: every single instruction would have an edge in the CFG to
every reachable exception handler. gcc is not set up to cope with
this.)
Andrew.