Re: [basic-improvements] try/finally support for c/c++ - more tests

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Nov 07, 2002 at 04:19:03PM -0800, Mark Mitchell wrote:
> > What you're asking for is that we have .eh_frame data, but that
> > we go look somewhere else when it comes time to decide if the
> > frame wants to handle exceptions.  This look-aside will have to
> > happen for each and every call frame, because we don't know which
> > frames are written in C and which aren't.
> 
> Couldn't it get a bit in its frame info to say whether or not it calls
> pthread_cleanup_push?  That would make the check pretty cheap.  (I'm
> not nearly as familiar as you with the format of that data; it might
> well be that there's no place to put that bit.)

You mean statically into .gcc_except_table, or dynamically?
Statically could be doable through some builtin and some hacks, dynamically
would be way harder.

> It has somewhat fancy semantics.  For example, you can catch
> floating-point exceptions this way and other things that would be
> signals in UNIX.  They have a "__leave" keyword; they have exception
> handling (as well as cleanups) and they have ways to say whether you
> keep unwinding, or stop where you are, when you hit the handler.
> 
> The aysnchronous exception aspect of their stuff is particularly
> interesting.
> 
> It's partly because of Microsoft's stuff that I'm so nervous about
> this feature.  Their semantics are not always what people expect, but
> ours probably won't match theirs, and the next thing that will happen
> will be that people will want to port "structured exception-handling"
> code to GCC, and then we'll be in trouble.

That's why the proposal is about __try/__finally only, not __except
where it is e.g. not clear at all what happens if you throw in C++
and __except control expression returns -1.
At least from what I read in MSFT docs on the web, their __try/__finally
matches Aldy's patch.

> I would prefer longjmp_unwind; that's something we're supposed to
> have anyhow, and it would be very useful in making existing C
> libraries play more nicely with C++, so implementing that would be
> a definite win.

longjmp_unwind would be good to have. But __builtin_setjmp has higher
runtime overhead than __try/__finally for pthread_cleanups (especially
on some architectures __builtin_setjmp is really expensive), plus
unless I misunderstood how longjmp_unwind is supposed to work,
longjmp_unwind needs to be passed address to the youngest jmp_buf on
the stack, which means maintaining a chain of nested jmp_buf's on the
stack with the head of the chain in some TLS variable (Richard, please
correct me if you have a better idea).
__try/__finally can well interact with longjmp_unwind - longjmp_unwind
would just call all the __finally blocks while unwinding
to the longjmp_unwind target.

	Jakub