This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Nonterminating exceptions with longjump?
- From: Gabor Greif <gabor at mac dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 4 Feb 2003 02:06:30 +0100
- Subject: Re: Nonterminating exceptions with longjump?
Am Montag den, 3. Februar 2003, um 14:20, schrieb Andrew Haley:
Gabor Greif writes:
I have a crazy idea for a long time but I did not dare to
articulate it till now. I know it is not standard-conformant,
but I just want to know whether it would work with g++.
I intend to simulate non-terminating exceptions on top of the
g++ exception handling machinery (sjlj-based or
table based, whatever).
As I understand it, non-terminating exceptions execute some code and
then either throw another exception or return. Signals do the same,
at least on systems that support throwing an exception from a signal
handler.
From what I remember, signals are meant to be invoked asyncronously
and their handlers are only allowed to set a volatile integer and return.
When signals are invoked syncronously they may have similar properties
and privileges like non-terminating exceptions.
But:
Can signal handlers pass on to the next handler in the call chain?
Are signals per-thread?
Can signal handlers easily access the local variables without resorting
to nested functions (GCC extension)?
Do signals utilize fast, table-based association of handlers to return
addresses?
What is the performance-cost of registering and unregistering signal
handlers for each function body?
What is the syntactical overhead of pulling such a stunt with signals?
So, in what way are non-terminating exceptions different from signals?
Depending on the answers to my above questions.
My motivation was to implement some kind of stack introspection, e.g.
- (infinite) recursion detection,
- stack marking for exact garbage collection,
- thread-global data (by acquiring a pointer to a local struct
in the thread entry)
- etc.
These things are rather easy to do in Dylan, which has non-terminating
conditions.
In the meantime I tried my example on CodeWarrior (PowerPC, v8.3)
and I get and infinite sequence of lines on the console.
GCC 2.95.2 aborts at the "throw" after the longjmp. So I guess my
suspicion is correct that I have to clear some flag to end exception
processing.
Tests with gcc 3.0 may come tomorrow.
Andrew.
Thanks for your interest,
Gabor
-- still curious knowing how I can avoid the abort() in gcc.