[LLVMdev] RFC: New Exception Handling Proposal

Bill Wendling wendling at apple.com
Tue Nov 24 13:05:34 PST 2009


On Nov 23, 2009, at 6:36 PM, Talin wrote:

> I have a couple of questions/concerns. The main one has to do with  
> the opacity of exception types - in other words, will it still be  
> true that the exception types are opaque identifiers, and are only  
> interpreted by the personality function?
>
> Since my object representations are not C++-like, I am not using any  
> of the cxa_* C++ library functions. Instead, my code calls the  
> _Unwind functions directly, and I have my own personality function  
> (which can be viewed here: http://code.google.com/p/tart/source/browse/trunk/runtime/lib/tart_eh_personality.c 
> )
>
> My compiler generates the list of filter parameters as pointers to  
> Type objects. In the personality function, it examines each such  
> pointer and does an IsSubclass test.  The action code returned by  
> the personality function is a simple integer index (0, 1, 2, ...etc)  
> which represents the number of the catch block to transfer control  
> to. This index is then fed into a IR switch instruction in the  
> landing pad.
>
> The concern I have is that the 'convoke' instuction takes a list of  
> catch types, but it doesn't say what those catch types are.  If the  
> code does not assume anything about them, then I'm guessing that I  
> would be able to adapt my code to work with it. On the other hand,  
> if those catch types are assumed to be C++ exceptions or RTTI  
> identifiers, then I'm hosed.
>
Yes. The whole point is not to tie the catch type to any language- 
specific type. And it should be able to handle using the Type objects.  
There may be some bitcasting involved, but that should be fairly  
straight-forward to deal with. Your way of implementing the EH control  
transfer to catch blocks is essentially how I'm handling it in my  
pseudo-example - assign each catch in the convoke an integer, and then  
switch on that integer after any potential clean-up code.

-bw




More information about the llvm-dev mailing list