Re: why does exception.cc have "unwinding" code for sjlj?

[Adam Megacz <gcj at lists dot megacz dot com>]

Richard Henderson <rth@redhat.com> writes:
> The call site table allows us to call setjmp just and handle any
> exception within the function.  The previous implementation had
> to call setjmp many times, which bloated the code quite a bit.

I don't quite understand... I thought that every time you entered a
try..catch block, you called setjmp and pushed the jmp_buf onto some
thread-local stack structure on the heap. Then, when an exception was
thrown, you call longjmp back to the nearest try..catch, which tries
to figure out if it can handle the exceptionand either does so or
longjmp()'s to the next jmp_buf down the stack.

If I'm not mistaken (I probably am), why does _Unwind_RaiseException
need to examine the call stack?


> > Adam Megacz writes:
> >  > The main problem I'm running into is that some of the unwind code
> >  > requires libstdc++ (specifically, #include <cstdlib>),
> 
> Well then use <stdlib.h> instead.

Hrm, some of the dependencies are in unwind-pe.h... I don't think many
people are going to want me mucking with that... arrgh.


> >  > Win32 never calls the _Unwind functions anyways; it just throws an
> >  > exception out of the signal handler.

> Err, if you didn't call _Unwind_RaiseException, you didn't throw
> an exception at all.

Oh, I guess I misunderstood. So the C++/Java compiler turns "throw"
statements into calls to _Unwind_RaiseException()?

  - a