[LLVMdev] RFC: New EH representation for MSVC compatibility

[Steve Cheng]

On 2015-05-18 18:11:29 -0400, Reid Kleckner said:
> 
> - Win32 (x86) frame-based SEH
> 
> But for __C_specific_handler, I see a potential issue versus x86-64, in 
> that RtlUnwind can't restore non-volatile registers, so when registers 
> are garbage when control is transferred to the landing pad.  When I 
> read the Itanium ABI documentation, it says that landing pads do get 
> non-volatile registers restored, so I guess that's probably the working 
> assumption of LLVM.
> 
> That's pretty frustrating, given that the xdata unwinder already knows 
> where the non-volatile registers are saved. Anyway, I think it can be 
> overcome in the backend with the right register allocation constraints.

I'm referring to 32-bit code here, i.e. the FS:[0] SEH frames, if I 
wasn't clear. There's no xdata on 32-bit.

> 
> __C_specific_handler's registration frame saves down EBP, but no other 
> registers, even ESP. If we use dynamic alloca or frame pointer 
> omission, we are dead in the water, right?
> 
> Are you sure the unwinder doesn't restore RSP? Anyway, the address of a 
> dynamic alloca can easily be spilled to the stack and reloaded.

Should be s/__C_specific_handler/__except_handler3/

I think ESP isn't reliable because there could be intermediate 
functions, in between where RaiseException got called and the target 
__except block, that do not install any SEH FS:[0] frames at all. Those 
intermediate functions might not need to run any SEH clean-up code 
themselves, but they could muck with registers in any way they like, 
expecting to restore them in their epilogues. But their epilogues don't 
get executed (or simulated), unlike in Win64.

> 
> I think LLVM has to know about the table format and landingpad PC 
> values, because that's its business. The RTTI data, though, is 
> completely between the frontend and the EH personality. I could imagine 
> a personality that uses an Itanium LSDA, but the RTTI pointers are 
> really pointers to functions that get called during phase 1 to 
> implement SEH filters. The new representation will actually allow you 
> to pass more data here to support passing in "adjectives" as required 
> for MSVC, but LLVM will have to know where to put it in the table and 
> there's no way to avoid that.

Perfect, I was wondering if you're re-designing EH in LLVM, would it 
support that.

Anyway, thank you, Reid, for patiently explaining this stuff to me. I 
think SEH's pretty decent and reasonable, but, __CxxFrameHandler3 is 
well, horrible...

Steve