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