[LLVMdev] Technical details discussion for SEH

[Kai Nacke]

Hi Jb,

with "real SEH handling" I mean "visual c++ style SEH".
With my patch it is possible to use the Windows SEH machinery but not 
with the _c_specific_handler from MSVC. You have to provide your own 
personality function which must work with the Dwarf encoding.

My patch is always linked to this wiki page: 
http://wiki.dlang.org/Building_and_hacking_LDC_on_Windows_using_MSVC. 
Just look for the section "Required source downloads".
An implementation of a personality function in D is here: 
https://github.com/ldc-developers/druntime/blob/ldc/src/ldc/eh2.d.
You can also look at libgcc on mingw64 and search for the implementation 
of __gcc_personality_seh0. That is the stuff which is supported by my patch.

I also think that the same mechanism can be implemented with 32bit SEH.

Regards,
Kai

On 31.01.2014 23:49, Jb Feldman wrote:
> 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
> <mailto: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
>     <mailto: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
>         <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 <mailto:LLVMdev at cs.uiuc.edu>
>         http://llvm.cs.uiuc.edu
>         http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev
>         <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>
>
>
>
>