[llvm-dev] seh / landing pads

[Carlo Kok via llvm-dev]

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