llvm dev - Jan 2014 - [LLVMdev] Technical details discussion for SEH

Hi Jb,

It's good to see someone step up and take a shot as this again. I dropped
this because it seems to me it wasn't a high priority task for LLVM/Clang.

Implementing SEH is more of LLVM work than Clang work.

For 32-bit SEH, there are prologue/epilogue instruction sequence to emit,
setting try-level ([ebp-4]), recovering EBP ([ebp-18h]), and all these can
only happen in LLVM, not Clang. In my opinion, we should implement these as
LLVM intrinsics, like the gcc ones: see
http://llvm.org/docs/ExceptionHandling.html#exception-handling-intrinsics.
Also, we should emit the tables for each function, which is not a simple
task either.

For 64-bit SEH, things are simpler. There are no more instructions to emit
than no-SEH code. We have only two tasks: emit the table for each function,
and place some code right. If I remember it correctly, __finally block code
should be replicated at 2 places: one in the original function as part of
the normal execution path, and other one separately if anything in __try
block goes south.
As for the table part, I've seen some commits from Kai(as CC'ed in this
email) doing it, you should ask him for details.

Thanks again.

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

Hi Jb, Hi Tong,

with my patch LLVM emits unwind information for Windows 64bit. The Dwarf 
EH encoding is used language specific data. That is the same way gcc 
implements SEH for Windows 64bit. (As a side note, PR18546 now contains 
a patch for Clang to use my patch on mingw64.)

The rational behind this approach is that Windows provides support for 
stack unwinding (RtlUnwind etc.) but LLVM is inherently based on Dwarf 
EH. This approach combine both worlds. If the personality function is 
tolerant enough then it should also be possible to mix exceptions.

If you want to make exception handling MS compatible then you can take 
my code as base. You only need to emit the MS handler data instead of 
the Dwarf data.

However, at least as a first approach I would recommend to implement 
32bit SEH with a similar approach. It should have some similarities to 
SjLj exception handling - this really helps to understand what needs to 
be done.

"real SEH handling" requires a small function which is called to
decide
if the exception is handled. If yes then the handler is called. If not 
then stack unwinding continues (after a possible call of a cleanup 
handler). I found it difficult (if not impossible) to create this code 
based on the exception design of LLVM. IMHO, some some generalizations 
are required.

Regards,
Kai

On 31.01.2014 05:29, endlessroad1991 at gmail.com wrote:
> Hi Jb,
>
> It's good to see someone step up and take a shot as this again. I
> dropped this because it seems to me it wasn't a high priority task for
> LLVM/Clang.
>
> Implementing SEH is more of LLVM work than Clang work.
>
> For 32-bit SEH, there are prologue/epilogue instruction sequence to
> emit, setting try-level ([ebp-4]), recovering EBP ([ebp-18h]), and all
> these can only happen in LLVM, not Clang. In my opinion, we should
> implement these as LLVM intrinsics, like the gcc ones: see
> http://llvm.org/docs/ExceptionHandling.html#exception-handling-intrinsics.
> Also, we should emit the tables for each function, which is not a simple
> task either.
>
> For 64-bit SEH, things are simpler. There are no more instructions to
> emit than no-SEH code. We have only two tasks: emit the table for each
> function, and place some code right. If I remember it correctly,
> __finally block code should be replicated at 2 places: one in the
> original function as part of the normal execution path, and other one
> separately if anything in __try block goes south.
> As for the table part, I've seen some commits from Kai(as CC'ed in
this
> email) doing it, you should ask him for details.
>
> Thanks again.
>
> --
> Best Regards, Tong Shen (沈彤)
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

Can you clarify what you mean by "real SEH handling"? My company has
me
looking at this in the hopes that I can make LLVM capable of building
windows drivers. If you mean "visual c++ style SEH", I'm fairly
sure that
isn't necessary for my purposes, but it would be nice. If you mean
"something that works at all," then your concern about generalizing
LLVM
exception handling probably means that I will need to do some work learning
about how exception handling is currently implemented. Do you have a link
to the patch your discussing, or a revision number?

Thanks,
JB


On Fri, Jan 31, 2014 at 6:41 AM, Kai Nacke <kai.nacke at redstar.de>
wrote:
> Hi Jb, Hi Tong,
>
> with my patch LLVM emits unwind information for Windows 64bit. The Dwarf
> EH encoding is used language specific data. That is the same way gcc
> implements SEH for Windows 64bit. (As a side note, PR18546 now contains a
> patch for Clang to use my patch on mingw64.)
>
> The rational behind this approach is that Windows provides support for
> stack unwinding (RtlUnwind etc.) but LLVM is inherently based on Dwarf EH.
> This approach combine both worlds. If the personality function is tolerant
> enough then it should also be possible to mix exceptions.
>
> If you want to make exception handling MS compatible then you can take my
> code as base. You only need to emit the MS handler data instead of the
> Dwarf data.
>
> However, at least as a first approach I would recommend to implement 32bit
> SEH with a similar approach. It should have some similarities to SjLj
> exception handling - this really helps to understand what needs to be done.
>
> "real SEH handling" requires a small function which is called to
decide if
> the exception is handled. If yes then the handler is called. If not then
> stack unwinding continues (after a possible call of a cleanup handler). I
> found it difficult (if not impossible) to create this code based on the
> exception design of LLVM. IMHO, some some generalizations are required.
>
> Regards,
> Kai
>
>
> On 31.01.2014 05:29, endlessroad1991 at gmail.com wrote:
>
>> Hi Jb,
>>
>> It's good to see someone step up and take a shot as this again. I
>> dropped this because it seems to me it wasn't a high priority task
for
>> LLVM/Clang.
>>
>> Implementing SEH is more of LLVM work than Clang work.
>>
>> For 32-bit SEH, there are prologue/epilogue instruction sequence to
>> emit, setting try-level ([ebp-4]), recovering EBP ([ebp-18h]), and all
>> these can only happen in LLVM, not Clang. In my opinion, we should
>> implement these as LLVM intrinsics, like the gcc ones: see
>>
http://llvm.org/docs/ExceptionHandling.html#exception-handling-intrinsics
>> .
>> Also, we should emit the tables for each function, which is not a
simple
>> task either.
>>
>> For 64-bit SEH, things are simpler. There are no more instructions to
>> emit than no-SEH code. We have only two tasks: emit the table for each
>> function, and place some code right. If I remember it correctly,
>> __finally block code should be replicated at 2 places: one in the
>> original function as part of the normal execution path, and other one
>> separately if anything in __try block goes south.
>> As for the table part, I've seen some commits from Kai(as CC'ed
in this
>> email) doing it, you should ask him for details.
>>
>> Thanks again.
>>
>> --
>> Best Regards, Tong Shen (沈彤)
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140131/1d711d31/attachment.html>