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

George Talbot george@moberg.com
Tue Aug 31 23:20:00 GMT 1999


On 19 Aug 1999, Jason Merrill wrote:

> >>>>> George T Talbot <george@moberg.com> writes:
> 
>  > Jason Merrill wrote:
>  >> 
>  >> No; cleanups are registered at compile time in the dwarf2 model.  You'll
>  >> need to extend the C frontend to add the notion of cleanups, like a try
>  >> ... finally construct, or a cleanup block construct.
> 
>  > Ugh.  This is starting to get beyond my skill level.  I can do the C
>  > library stuff, but I'm not sure I understand how to extend the compiler
>  > this way.
> 
> Actually, the simplest approach would be to make them builtin functions,
> __builtin_cleanup_push (routine, arg) and __builtin_cleanup_pop (execute).
> You would call expand_eh_region_start_tree in stmt.c to register the
> cleanup, and if execute is true when popping, extract the cleanup info from
> the ehstack and run it directly.  It would be hard to map the existing API
> onto try ... finally.

So, these would be functions that GCC would generate into the program
on-the-fly?  Makes sense.

>  >>  > If I can do that, then I can rewrite pthread_cleanup_push() and
>  >>  > pthread_cleanup_pop() to work with the exception mechanism and I can
>  >>  > rewrite pthread_cancel() to throw an exception.
>  >> 
>  >> push and pop would need to be macros.
> 
>  > Yup.  They are now, if you look at pthreads.h.
> 
> And I see that they are required to be symmetrical, at the same nesting
> level.  Good; this is crucial for the compile-time approach to work.

The POSIX standard is written that way for just this issue.

-George

P.S.  Thanks for helping me work through this.




More information about the Gcc mailing list