llvm dev - May 2009 - [LLVMdev] the different semantics between dwarf-eh and sjlj-eh

Hi,

>> from the exist llvm-ir it seems there are some common info for sjlj-eh
>> and  dwarf-eh!
>> are there possible use the exist llvm-ir to generate exception table
> >for sjlj-eh ?
>No. There should be support from llvm-gcc. sjlj eh and dwarf eh have
>different semantics
different semantics ?  !
I think llvm-gcc generate the IR should not include the exception
runtime lib info, so support  dwarf-eh and sjlj-eh should be
delay to the llvm back-end or target platform . and the specific
target codegen the same IR to different exception style code !

Hello,
> I think llvm-gcc generate the IR should not include the exception
> runtime lib info, so support  dwarf-eh and sjlj-eh should be
> delay to the llvm back-end or target platform . and the specific
> target codegen the same IR to different exception style code !
This is not possible, unfortunately. There *should* be support from
frontend. Different styles of exceptions share some stuff, but still
have differences.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On May 6, 2009, at 11:41 PM, zhengjian zhang wrote:
>>> from the exist llvm-ir it seems there are some common info for  
>>> sjlj-eh
>>> and  dwarf-eh!
>>> are there possible use the exist llvm-ir to generate exception
table
>>> for sjlj-eh ?
>
>> No. There should be support from llvm-gcc. sjlj eh and dwarf eh have
>> different semantics
>
> different semantics ?  !
> I think llvm-gcc generate the IR should not include the exception
> runtime lib info, so support  dwarf-eh and sjlj-eh should be
> delay to the llvm back-end or target platform . and the specific
> target codegen the same IR to different exception style code !
Exception handling should definitely be handled, as much as possible,  
in the non-target specific code. There is very little target  
information required, and what there is can be handled with a few  
careful hooks.

On the other hand, it's not completely possible to separate it from  
the front end either since different languages can have different  
semantics. Ada, C++, Objective C, etc.. Sometimes these can be handled  
the same way under the hood, but it's dangerous for the compiler to  
assume that to be true. At least some knowledge needs to be in the  
front end code-gen.

I should have some draft code ready soon (within a few days) that  
demonstrates some of this. I don't know if it will meet your needs,  
but if not, it should provide a starting point.

-Jim