[PATCH] ntdll: Only call wine exception handlers on the current stack.

[Jacek Caban]

On 2/1/22 16:24, Paul Gofman wrote:
> On 2/1/22 18:06, Jacek Caban wrote:
>> On 2/1/22 13:57, Paul Gofman wrote:
>>> Not sure though if that is good enough though, the prior 
>>> understanding was that these sort of fixes are waiting for mingw 
>>> .seh support.
>>
>>
>> It's not just SEH support that's missing in mingw (in fact, GCC mingw 
>> already supports SEH on x86_64 and llvm-mingw on all targets), but 
>> it'd also need some sort of __try/__except support (or something 
>> similar), which is not present in GCC.
>>
> If by SEH support you mean generating .SEH unwind info for functions 
> then yes, of course, not sure how things would work without at all in 
> x64 PE (although without a way to link exception handler, that is, 
> __try / __except). If you mean .seh catch on the asm level than yes, 
> that's how I am suggesting to do that for the select function or two 
> like RtlUserThreadStart. Or do you mean some other support?


I think that ideally we'd use SEH for all Wine internal exception 
handling. For that, we'd need something that can be used for Wine 
__TRY/__EXCEPT macros and MSVC-style __try/__except syntax seems like a 
perfect fit, but I can imagine that one could come out with some other 
solution. I think that it's not possible with current state of SEH in GCC.


>>
>> clang already supports it on all targets. I gave it a try when I was 
>> working on clang support and it looked promising. Back then, I 
>> decided to put it aside until clang builds are generally in a better 
>> shape. I just gave it another quick look and with the attached patch, 
>> I was able to build x64_64 Wine. Unfortunately it fails to run 
>> iexplore (my quick test), so there is more work needed. If you'd like 
>> to give it a try, use something like this for configure:
>
> Please correct me if I am wrong, but it seems like having clang as the 
> default build looks like a long shot for now.


 From what I know, the only thing that such are currently missing is 
support for hotpachable images. There was some work done on this in 
LLVM, but it's not yet complete. On top of that, such builds are 
obviously less tested, but I think that it's not unrealistic for 
projects like Proton to use clang with enough efforts.


> The asm solution should be functionally correct and work both on gcc 
> and clang (I presume? I think I tried ".seh_handler handler_func, 
> @except" on clang some time ago although need to recheck). Of course 
> it may still appear a no go due to inherent ugliness and not targeting 
> arm64.


I think that the main problem is that we don't want to rewrite every 
function using __TRY/__EXCEPT in assembly. If converting selected few 
functions buys us enough benefits, I don't think it's out of the 
question. But long term, for proper support, I think that compiler 
support is the way to go. It's not impossible to support that in GCC as 
well, it's just a lot of work on GCC itself.


Jacek