Help: Unwinding the C++ stack...throw, longjmp & threads

[George T. Talbot]

Jason Merrill wrote:
> 
> >>>>> Richard Henderson <rth@cygnus.com> writes:
> 
>  > We should instead figure out why the 5% performance degradation
>  > and fix it.
> 
> Agreed, though that isn't an option where we don't control libc.
> 
>  > IN THEORY, it shouldn't matter -- the complexity to compilation comes
>  > when you have exception handlers, not throws.  We should not care that
>  > some called function throws through any more than we care if they
>  > longjmp though.
> 
> Agreed.
> 
>  > Probably it is the case that some pass that has yet to be
>  > converted to the properly use the new CFG is misinterpreting
>  > basic block boundaries in the presence of flag_exceptions.
> 
> regmove.c says
> 
>       /* ??? We can't scan past the end of a basic block without updating
>          the register lifetime info (REG_DEAD/basic_block_live_at_start).
>          A CALL_INSN might be the last insn of a basic block, if it is
>          inside an EH region.  There is no easy way to tell, so we just
>          always break when we see a CALL_INSN if flag_exceptions is
>          nonzero.  */
> 
> But as you say, this is unnecessary for code that contains no exception
> regions, such as all C code.

Considering what should probably happen on pthread_cancel(), which is
unwinding both the C cleanup handlers and the C++ stack frames (and
possibly catch(...){ }), that tells me that some method of hooking into
exception handlers from C needs to be in GCC.  I refer to Dave
Butenhof's e-mail.  This is what happens in the 64-bit UNIX system that
he's working on at Compaq (was DEC).

It seems to me that the C library, which implements pthreads under
Linux, needs to implement deferred cancellation as an exception, with C
cleanup handlers using the same mechanism as C++ exception handlers &
stack-based object destructors.

Does this sound right?

--
George T. Talbot
<george@moberg.com>