[llvm-commits] [llvm] r97757 - /llvm/trunk/lib/CodeGen/SjLjEHPrepare.cpp

Jim Grosbach grosbach at apple.com
Fri Mar 5 11:28:11 PST 2010


On Mar 5, 2010, at 1:17 AM, Duncan Sands wrote:

> Hi Jim,
> 
>> For SJLJ exception handling, make sure that all calls that are not marked
>> as nounwind are marked with a -1 call-site value. This is necessary to, for
>> example, correctly process exceptions thrown from within an "unexpected"
>> execption handler (see SingleSource/Regression/C++/EH/expection_spec_test.cpp).
> 
> a similar issue occurs with dwarf exception handling (there every call that is
> allowed to unwind must be part of a call-site entry with a null landing pad -
> calls with no call-site that unwind are considered to be an error by the C++
> personality, which terminates the program).  The code generator tiles the entire
> function with call-sites: real call-sites for invokes, and between them a site
> with a region that stretches from the end of one invoke to the start of the next
> and with a null landing pad.  (As an optimization it doesn't bother generating
> such a region if there is nothing that can throw inside it).  Does SjLj use the
> dwarf writer?  If so, maybe it can squeeze what it needs out of the existing
> logic somehow.

SjLj does use the dwarf writer for emitting the exception table, yes. That runs much too late to help with this issue, however, as SjLj needs to insert the call site marker into the instruction stream as a store into the function context. Dwarf can do it much later since everything is encapsulated in the exception table.

You're right that it's effectively the same issue. Long term, I'm hopeful there will be able to me more code-sharing for this sort of thing. To do so, however, more of the logic will need brought forward before the asmprinter. <handwaving>I'm thinking of a late pass right before PEI that does the necessary analysis and markup. Target hooks would be used to insert the actual code sequences needed by sjlj (lots of the stuff could be handled via existing hooks like storeToStackSlot() and such). Doing that would obviate the need for at least some of the sjlj intrinsics, which would make me very happy. It would also possibly clean up some of the lost/found landing pad type stuff. </handwaving>

-Jim



More information about the llvm-commits mailing list