[cfe-dev] [RFC] Win32 SEH Implementation

[endlessroad1991 at gmail.com]

Hi all,

It seems that MSVC ABI is reaching a somehow usable state, except:
- Byval argument passing (ongoing)
- RTTI, which I think is not particularly difficult. 3 part of work: emit
RTTI related structures, translate dynamic_cast to a library call
RTDynamicCast, and translate typeid() to a library call RTTypeId
- C++ exceptions, which is based on SEH. This is what I want to talk about
here.

For C++ exceptions, we have to tackle SEH first. I understand Win32 SEH is
under patent protection, but the patent will expire on April 2014. So do
you think it's time we can start working on it? If that's the situation,
here's some initial thought about the implementation.

I looked into Win32 SEH implementation a bit. On the compiler side, the
following is needed:
- Generate a table struct for each function that utilizes SEH, containing
info like __except/__finally block address, etc. Should be easy.
- Extra instructions in prologue and epilogue. For extra epilogue
instructions, we can treat them as intrinsic instead of epilogue. But for
prologue it's a different story: some instructions happen before actual
prologue(alloca & register saving). My plan is add an attribute to
llvm::Function.
- To identify which __try block we are in, [ebp - 4] is used to store block
id. To set it, there are "mov [bep-4], XXX" at the beginning and end of
each __try block. A new llvm intrinsic for this?
- At the beginning of __except block, esp is restored using "mov esp, [ebp
- 0x18]". A new llvm intrinsic for this?
- If __try is paired with __finally, there will be a "call
address_of_finally" in the end of the __try block. We cannot extract
__finally block to a separate function, because the block may need access
to local variables in the containing function. A new llvm intrinsic for
this?
- __except filter code ends with "mov eax, result;    ret" (return
statement of "int func(void)"), and __finally block ends with "ret" (return
statement of "void func(void)"). The containing function may have different
return types; are these 2 considered valid by llvm? If not, we may need
intrinsic for these.

-- 
Best Regards, Tong Shen (沈彤)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131115/dbf7b403/attachment.html>