llvm dev - Sep 2016 - seh / landing pads

In the past people in #llvm suggested to me I should use landing pads 
instead of seh when it comes to Windows unless i really need seh. 
Looking at what gets generated win64 -gnu does use seh but calls the 
landing pad somehow, while win32 doesn't at all. It looks to me a custom 
win64 landing pad personality can also deal with things like Access 
Violation. Is there a way to make win32 also able to catch say access 
violation but still use landing pads?

Also are there open source Unwind* implementions that work on windows, 
that anyone knows of?
-- 
Carlo Kok

Yes, it is definitely technically feasible to catch access violations with
landingpads, but it will involve writing your own EH personality, probably
by starting with the one from libgcc.

The major consideration for whether to use a landingpad EH personality or a
funclet-based EH personality is, do you need to be compatible with MSVC EH?
That is, do you want destructors in MSVC frames to run if your exception is
thrown, and do you want to clean up if an MSVC C++ exception unwinds
through your stack frame? If yes, then you need to use the new EH
instructions (catchpad). If no, then you'll get better code if you use
landingpad.

I also want to try to unpack what you mean when you say "landing pads
instead of seh" and "win64-gnu does use seh but calls the landingpad
somehow". SEH is a very overloaded term. Here are the two things people
usually mean by it:
- The mechanisms used to unwind the stack on Windows, either for 32-bit or
64-bit x86 (.seh_* directives)
- The MSVC language mechanism for catching non-call exceptions in a
structured manner (__try / __except)

Every major compiler on Win64 implements the standard stack unwind
information format that Microsoft specified at https://msdn.microsoft.com/
en-us/library/0kd71y96.aspx. This corresponds to the .seh_* assembler
directives that GCC, gas, and LLVM use on Win64, which is what you're
seeing.

x86_32 Windows uses a less sophisticated unwind mechanism involving a
linked list maintained in TLS at fs:00. Sometimes people use SEH to refer
to this and related structures.

On Wed, Sep 28, 2016 at 11:56 AM, Carlo Kok via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> In the past people in #llvm suggested to me I should use landing pads
> instead of seh when it comes to Windows unless i really need seh. Looking
> at what gets generated win64 -gnu does use seh but calls the landing pad
> somehow, while win32 doesn't at all. It looks to me a custom win64
landing
> pad personality can also deal with things like Access Violation. Is there a
> way to make win32 also able to catch say access violation but still use
> landing pads?
>
> Also are there open source Unwind* implementions that work on windows,
> that anyone knows of?
> --
> Carlo Kok
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160929/c3411052/attachment.html>

On 2016-09-29 23:30, Reid Kleckner wrote:
> Yes, it is definitely technically feasible to catch access violations
> with landingpads, but it will involve writing your own EH personality,
> probably by starting with the one from libgcc.
>
> The major consideration for whether to use a landingpad EH personality
> or a funclet-based EH personality is, do you need to be compatible with
> MSVC EH? That is, do you want destructors in MSVC frames to run if your
> exception is thrown, and do you want to clean up if an MSVC C++
> exception unwinds through your stack frame? If yes, then you need to use
> the new EH instructions (catchpad). If no, then you'll get better code
> if you use landingpad.
>
> I also want to try to unpack what you mean when you say "landing pads
> instead of seh" and "win64-gnu does use seh but calls the
landingpad
> somehow". SEH is a very overloaded term. Here are the two things
people
> usually mean by it:
> - The mechanisms used to unwind the stack on Windows, either for 32-bit
> or 64-bit x86 (.seh_* directives)
> - The MSVC language mechanism for catching non-call exceptions in a
> structured manner (__try / __except)
>
> Every major compiler on Win64 implements the standard stack unwind
> information format that Microsoft specified
> at https://msdn.microsoft.com/en-us/library/0kd71y96.aspx
> <https://msdn.microsoft.com/en-us/library/0kd71y96.aspx>. This
> corresponds to the .seh_* assembler directives that GCC, gas, and LLVM
> use on Win64, which is what you're seeing.
thanks for the extensive reply. This sounds exactly like what I want.
>
> x86_32 Windows uses a less sophisticated unwind mechanism involving a
> linked list maintained in TLS at fs:00. Sometimes people use SEH to
> refer to this and related structures.
But the landingpad stuff on x86_32 won't use fs:00 will it? Can I still 
use it to catch access violations and other internal exception types?


-- 
Carlo Kok
RemObjects Software