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

[Andrew Haley <aph at cambridge dot redhat dot com>]

Richard,

We're baffled by this.  Why does SJLJ_EXCEPTIONS code need the
call-site table?  Something to do with

  // FIXME2: _Unwind_GetIP is nonsensical for SJLJ, being a call-site
  // index instead of a PC value.  We could perhaps arrange for
  // _Unwind_GetRegionStart to return context->fc->jbuf[1], which
  // is the address of the handler label for __builtin_longjmp, but
  // there is no solution for DONT_USE_BUILTIN_SETJMP.

?

Thanks,
Andrew.


Adam Megacz writes:
 > 
 > I don't get it -- I thought the whole point of SJLJ was that you
 > couldn't meaningfully "unwind" the stack to get a stack trace. Isn't
 > that [part of] what makes DWARF2 better than SJLJ?
 > 
 > #ifdef SJLJ_EXCEPTIONS
 >   // The given "IP" is an index into the call-site table, with two
 >   // exceptions -- -1 means no-action, and 0 means terminate.  But
 >   // since we're using uleb128 values, we've not got random access
 >   // to the array.
 >   if ((int) ip <= 0)
 >     return _URC_CONTINUE_UNWIND;
 >   else
 >     {
 >       _Unwind_Word cs_lp, cs_action;
 >       do
 >         {
 >           p = read_uleb128 (p, &cs_lp);
 > ....
 > 
 > The main problem I'm running into is that some of the unwind code
 > requires libstdc++ (specifically, #include <cstdlib>), but libstdc++
 > has a lot of problems crosscompiling, and I'd rather just not build it
 > than try to get my (ugly) patches to its configure.in accepted; I'd
 > probably break more stuff than I would fix, anyways...
 > 
 > Win32 never calls the _Unwind functions anyways; it just throws an
 > exception out of the signal handler.
 > 
 > Suggestions on how to deal with this?
 > 
 >   - a