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