[PATCH] ntdll: Only call wine exception handlers on the current stack.
MK11 creates an alternate stack and sometimes throws an exception which gets incorrectly handled by a Wine exception handler, causing the game to crash. Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- dlls/ntdll/signal_x86_64.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c index 7e77329363c..36985832e4a 100644 --- a/dlls/ntdll/signal_x86_64.c +++ b/dlls/ntdll/signal_x86_64.c @@ -463,7 +463,9 @@ static NTSTATUS call_stack_handlers( EXCEPTION_RECORD *rec, CONTEXT *orig_contex } } /* hack: call wine handlers registered in the tib list */ - else while ((ULONG64)teb_frame < context.Rsp) + else while ((ULONG64)teb_frame < context.Rsp && + (ULONG64)teb_frame >= (ULONG64)NtCurrentTeb()->Tib.StackLimit && + (ULONG64)teb_frame <= (ULONG64)NtCurrentTeb()->Tib.StackBase) { TRACE_(seh)( "found wine frame %p rsp %p handler %p\n", teb_frame, (void *)context.Rsp, teb_frame->Handler ); -- 2.34.1
On 1/31/22 18:24, Rémi Bernon wrote:
MK11 creates an alternate stack and sometimes throws an exception which gets incorrectly handled by a Wine exception handler, causing the game to crash.
Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- dlls/ntdll/signal_x86_64.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c index 7e77329363c..36985832e4a 100644 --- a/dlls/ntdll/signal_x86_64.c +++ b/dlls/ntdll/signal_x86_64.c @@ -463,7 +463,9 @@ static NTSTATUS call_stack_handlers( EXCEPTION_RECORD *rec, CONTEXT *orig_contex } } /* hack: call wine handlers registered in the tib list */ - else while ((ULONG64)teb_frame < context.Rsp) + else while ((ULONG64)teb_frame < context.Rsp && + (ULONG64)teb_frame >= (ULONG64)NtCurrentTeb()->Tib.StackLimit && + (ULONG64)teb_frame <= (ULONG64)NtCurrentTeb()->Tib.StackBase)
The same change should in theory go to RtlUnwindEx() and RtlRestoreContext()? Although now after thinking a bit more about it I don't quite understand how this is going to work when thread is switching stack. When switching stack on i386 where TIB handlers belong that involves switching Tib.ExceptionList as well (see, e. g., kernelbase/thread.c:SwitchToFiber(). If the stack is switched but the ExceptionList is not there will be a mix of frames between the two stacks in the Teb list, popping those frames probably won't work right after switching. Do you know how the game is switching stack? Maybe I am missing something but IMO without knowing some details on how the game is doing that the only real way to solve it is to get rid of the ExceptionList hack on x64 (which is possible to do but in a not particularly nice way in the absence of .seh handlers support in mingw).
Am 31.01.22 um 16:24 schrieb Rémi Bernon:
MK11 creates an alternate stack and sometimes throws an exception which gets incorrectly handled by a Wine exception handler, causing the game to crash.
Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- dlls/ntdll/signal_x86_64.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c index 7e77329363c..36985832e4a 100644 --- a/dlls/ntdll/signal_x86_64.c +++ b/dlls/ntdll/signal_x86_64.c @@ -463,7 +463,9 @@ static NTSTATUS call_stack_handlers( EXCEPTION_RECORD *rec, CONTEXT *orig_contex } } /* hack: call wine handlers registered in the tib list */ - else while ((ULONG64)teb_frame < context.Rsp) + else while ((ULONG64)teb_frame < context.Rsp && + (ULONG64)teb_frame >= (ULONG64)NtCurrentTeb()->Tib.StackLimit && + (ULONG64)teb_frame <= (ULONG64)NtCurrentTeb()->Tib.StackBase) { TRACE_(seh)( "found wine frame %p rsp %p handler %p\n", teb_frame, (void *)context.Rsp, teb_frame->Handler );
I am not sure but this seems kind of similar to what I think I found in this bug: https://bugs.winehq.org/show_bug.cgi?id=52159
On 2/1/22 14:54, Bernhard Übelacker wrote:
Am 31.01.22 um 16:24 schrieb Rémi Bernon:
MK11 creates an alternate stack and sometimes throws an exception which gets incorrectly handled by a Wine exception handler, causing the game to crash.
Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- dlls/ntdll/signal_x86_64.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c index 7e77329363c..36985832e4a 100644 --- a/dlls/ntdll/signal_x86_64.c +++ b/dlls/ntdll/signal_x86_64.c @@ -463,7 +463,9 @@ static NTSTATUS call_stack_handlers( EXCEPTION_RECORD *rec, CONTEXT *orig_contex } } /* hack: call wine handlers registered in the tib list */ - else while ((ULONG64)teb_frame < context.Rsp) + else while ((ULONG64)teb_frame < context.Rsp && + (ULONG64)teb_frame >= (ULONG64)NtCurrentTeb()->Tib.StackLimit && + (ULONG64)teb_frame <= (ULONG64)NtCurrentTeb()->Tib.StackBase) { TRACE_(seh)( "found wine frame %p rsp %p handler %p\n", teb_frame, (void *)context.Rsp, teb_frame->Handler );
I am not sure but this seems kind of similar to what I think I found in this bug: https://bugs.winehq.org/show_bug.cgi?id=52159
Yes, that looks quite similar. All these fix attempts workaround the problem where it is first visibly hit (calling wrong handler) but ignore what may happen to these handlers after. What if the app, e. g., switches stack back? And RtlUnwindEx()? Actually the majority of Wine __TRY blocks should have rather low chances to hit app's stack switch in between the handler is installed and removed (unless the app is doing something really fun with hotpatching). Those IsBad..Ptr(), a bunch of cases when the parameter access is wrapped into __TRY, OutputDebugString() are not much likely to hit such an issue. There are relatively few __TRY blocks which embrace application functions: calling thread func, calling DLL entry points, exception handlers calls in signal_x86_64.c (and maybe I missed some). Since you probably hit the issue with Proton that is not the nested exception handlers as those in Proton already have manual asm wrappers to use straightforward x64 .seh handling and don't install Teb handlers. If maybe there are just one or two of other "global" handlers which are problematic maybe it worth solving the issue with some sort of manual .seh specifically for those ones?
On 2/1/22 13:25, Paul Gofman wrote:
On 2/1/22 14:54, Bernhard Übelacker wrote:
Am 31.01.22 um 16:24 schrieb Rémi Bernon:
MK11 creates an alternate stack and sometimes throws an exception which gets incorrectly handled by a Wine exception handler, causing the game to crash.
Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- dlls/ntdll/signal_x86_64.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c index 7e77329363c..36985832e4a 100644 --- a/dlls/ntdll/signal_x86_64.c +++ b/dlls/ntdll/signal_x86_64.c @@ -463,7 +463,9 @@ static NTSTATUS call_stack_handlers( EXCEPTION_RECORD *rec, CONTEXT *orig_contex } } /* hack: call wine handlers registered in the tib list */ - else while ((ULONG64)teb_frame < context.Rsp) + else while ((ULONG64)teb_frame < context.Rsp && + (ULONG64)teb_frame >= (ULONG64)NtCurrentTeb()->Tib.StackLimit && + (ULONG64)teb_frame <= (ULONG64)NtCurrentTeb()->Tib.StackBase) { TRACE_(seh)( "found wine frame %p rsp %p handler %p\n", teb_frame, (void *)context.Rsp, teb_frame->Handler );
I am not sure but this seems kind of similar to what I think I found in this bug: https://bugs.winehq.org/show_bug.cgi?id=52159
Yes, that looks quite similar. All these fix attempts workaround the problem where it is first visibly hit (calling wrong handler) but ignore what may happen to these handlers after. What if the app, e. g., switches stack back? And RtlUnwindEx()?
Actually the majority of Wine __TRY blocks should have rather low chances to hit app's stack switch in between the handler is installed and removed (unless the app is doing something really fun with hotpatching). Those IsBad..Ptr(), a bunch of cases when the parameter access is wrapped into __TRY, OutputDebugString() are not much likely to hit such an issue. There are relatively few __TRY blocks which embrace application functions: calling thread func, calling DLL entry points, exception handlers calls in signal_x86_64.c (and maybe I missed some). Since you probably hit the issue with Proton that is not the nested exception handlers as those in Proton already have manual asm wrappers to use straightforward x64 .seh handling and don't install Teb handlers. If maybe there are just one or two of other "global" handlers which are problematic maybe it worth solving the issue with some sort of manual .seh specifically for those ones?
In the case of MK11, the wine handler is the one installed by RtlUserThreadStart. I don't see anywhere any clue about how the thread is switching stacks, it just happens to use alternate stacks after a while, and has actually quite a few different stacks, probably re-implementing its own fibers (it doesn't call SwitchToFiber). When they switch stacks they don't change the ExceptionList pointer though (probably as I understand it because it's not supposed to be used on Win64), so it's always ultimately pointing to the initial handler on the initial stack. There's then still quite a lot of Wine exception handlers being pushed / poped (IsBadString, C++ dynamic casts, etc...), though they don't usually callback any user code. -- Rémi Bernon <rbernon(a)codeweavers.com>
On 2/1/22 15:49, Rémi Bernon wrote:
On 2/1/22 13:25, Paul Gofman wrote:
On 2/1/22 14:54, Bernhard Übelacker wrote:
Am 31.01.22 um 16:24 schrieb Rémi Bernon:
MK11 creates an alternate stack and sometimes throws an exception which gets incorrectly handled by a Wine exception handler, causing the game to crash.
Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- dlls/ntdll/signal_x86_64.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c index 7e77329363c..36985832e4a 100644 --- a/dlls/ntdll/signal_x86_64.c +++ b/dlls/ntdll/signal_x86_64.c @@ -463,7 +463,9 @@ static NTSTATUS call_stack_handlers( EXCEPTION_RECORD *rec, CONTEXT *orig_contex } } /* hack: call wine handlers registered in the tib list */ - else while ((ULONG64)teb_frame < context.Rsp) + else while ((ULONG64)teb_frame < context.Rsp && + (ULONG64)teb_frame >= (ULONG64)NtCurrentTeb()->Tib.StackLimit && + (ULONG64)teb_frame <= (ULONG64)NtCurrentTeb()->Tib.StackBase) { TRACE_(seh)( "found wine frame %p rsp %p handler %p\n", teb_frame, (void *)context.Rsp, teb_frame->Handler );
I am not sure but this seems kind of similar to what I think I found in this bug: https://bugs.winehq.org/show_bug.cgi?id=52159
Yes, that looks quite similar. All these fix attempts workaround the problem where it is first visibly hit (calling wrong handler) but ignore what may happen to these handlers after. What if the app, e. g., switches stack back? And RtlUnwindEx()?
Actually the majority of Wine __TRY blocks should have rather low chances to hit app's stack switch in between the handler is installed and removed (unless the app is doing something really fun with hotpatching). Those IsBad..Ptr(), a bunch of cases when the parameter access is wrapped into __TRY, OutputDebugString() are not much likely to hit such an issue. There are relatively few __TRY blocks which embrace application functions: calling thread func, calling DLL entry points, exception handlers calls in signal_x86_64.c (and maybe I missed some). Since you probably hit the issue with Proton that is not the nested exception handlers as those in Proton already have manual asm wrappers to use straightforward x64 .seh handling and don't install Teb handlers. If maybe there are just one or two of other "global" handlers which are problematic maybe it worth solving the issue with some sort of manual .seh specifically for those ones?
In the case of MK11, the wine handler is the one installed by RtlUserThreadStart.
Yes, RtlUserThreadStart() is the one which will always be there. So if we replace that single one with an asm wrapper (and there is already a wrapper for i386) we will likely solve the big share of practical issues in a straightforward way. I can make such a patch (unless you want to do it?). Not sure though if that is good enough though, the prior understanding was that these sort of fixes are waiting for mingw .seh support. I suppose MK11 will work this way (e. g., works with just removing __TRY in RtlUserThreadStart())?
I don't see anywhere any clue about how the thread is switching stacks, it just happens to use alternate stacks after a while, and has actually quite a few different stacks, probably re-implementing its own fibers (it doesn't call SwitchToFiber).
When they switch stacks they don't change the ExceptionList pointer though (probably as I understand it because it's not supposed to be used on Win64), so it's always ultimately pointing to the initial handler on the initial stack.
Yes, sure, they should not, ExceptionList on x64 is a Wine thing.
On 2/1/22 13:57, Paul Gofman wrote:
On 2/1/22 15:49, Rémi Bernon wrote:
On 2/1/22 13:25, Paul Gofman wrote:
On 2/1/22 14:54, Bernhard Übelacker wrote:
Am 31.01.22 um 16:24 schrieb Rémi Bernon:
MK11 creates an alternate stack and sometimes throws an exception which gets incorrectly handled by a Wine exception handler, causing the game to crash.
Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> --- dlls/ntdll/signal_x86_64.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c index 7e77329363c..36985832e4a 100644 --- a/dlls/ntdll/signal_x86_64.c +++ b/dlls/ntdll/signal_x86_64.c @@ -463,7 +463,9 @@ static NTSTATUS call_stack_handlers( EXCEPTION_RECORD *rec, CONTEXT *orig_contex } } /* hack: call wine handlers registered in the tib list */ - else while ((ULONG64)teb_frame < context.Rsp) + else while ((ULONG64)teb_frame < context.Rsp && + (ULONG64)teb_frame >= (ULONG64)NtCurrentTeb()->Tib.StackLimit && + (ULONG64)teb_frame <= (ULONG64)NtCurrentTeb()->Tib.StackBase) { TRACE_(seh)( "found wine frame %p rsp %p handler %p\n", teb_frame, (void *)context.Rsp, teb_frame->Handler );
I am not sure but this seems kind of similar to what I think I found in this bug: https://bugs.winehq.org/show_bug.cgi?id=52159
Yes, that looks quite similar. All these fix attempts workaround the problem where it is first visibly hit (calling wrong handler) but ignore what may happen to these handlers after. What if the app, e. g., switches stack back? And RtlUnwindEx()?
Actually the majority of Wine __TRY blocks should have rather low chances to hit app's stack switch in between the handler is installed and removed (unless the app is doing something really fun with hotpatching). Those IsBad..Ptr(), a bunch of cases when the parameter access is wrapped into __TRY, OutputDebugString() are not much likely to hit such an issue. There are relatively few __TRY blocks which embrace application functions: calling thread func, calling DLL entry points, exception handlers calls in signal_x86_64.c (and maybe I missed some). Since you probably hit the issue with Proton that is not the nested exception handlers as those in Proton already have manual asm wrappers to use straightforward x64 .seh handling and don't install Teb handlers. If maybe there are just one or two of other "global" handlers which are problematic maybe it worth solving the issue with some sort of manual .seh specifically for those ones?
In the case of MK11, the wine handler is the one installed by RtlUserThreadStart.
Yes, RtlUserThreadStart() is the one which will always be there. So if we replace that single one with an asm wrapper (and there is already a wrapper for i386) we will likely solve the big share of practical issues in a straightforward way. I can make such a patch (unless you want to do it?). Not sure though if that is good enough though, the prior understanding was that these sort of fixes are waiting for mingw .seh support.
Well if it's better than checking the handler location go for it, I'm not sure to see what that wrapper would need to be doing.
I suppose MK11 will work this way (e. g., works with just removing __TRY in RtlUserThreadStart())?
Yes. -- Rémi Bernon <rbernon(a)codeweavers.com>
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. 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: configure CROSSCC=clang CROSSCFLAGS="-g -O2 -DUSE_COMPILER_EXCEPTIONS" --enable-win64 Jacek
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?
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. 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.
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
On 2/1/22 18:51, Jacek Caban wrote:
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.
Yes, sure, compiler support is how that is supposed to be, the only question is whether having a manual fix for a function or two is too bad. I think I will make that so it can be viewed at least.
On Tue, 1 Feb 2022, 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),
Just a minor clarification here - the above statement is true for x86_64 and aarch64; clang uses SEH on those architectures in both MSVC and mingw mode. For i386, clang does use the MSVC exception handling mechanism in MSVC mode, but in mingw mode, it uses dwarf instead (and can use sjlj as an alternative). For arm32, it doesn't support SEH generation at all. (In MSVC mode, it just refuses to generate unwind information, and in mingw mode, it defaults to dwarf). // Martin
On 2/1/22 16:25, Martin Storsjö wrote:
On Tue, 1 Feb 2022, 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),
Just a minor clarification here - the above statement is true for x86_64 and aarch64; clang uses SEH on those architectures in both MSVC and mingw mode.
For i386, clang does use the MSVC exception handling mechanism in MSVC mode, but in mingw mode, it uses dwarf instead (and can use sjlj as an alternative).
Thanks for clarification. I thought there was a way to force SEH on i386 in mingw mode. I can't find it now, but I recall some discussions and Firefox trying to use it with their clang mingw builds (without much success). I must remember it wrong. Thanks, Jacek
On 2/2/22 01:00, Jacek Caban wrote:
On 2/1/22 16:25, Martin Storsjö wrote:
On Tue, 1 Feb 2022, 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),
Just a minor clarification here - the above statement is true for x86_64 and aarch64; clang uses SEH on those architectures in both MSVC and mingw mode.
For i386, clang does use the MSVC exception handling mechanism in MSVC mode, but in mingw mode, it uses dwarf instead (and can use sjlj as an alternative).
Thanks for clarification. I thought there was a way to force SEH on i386 in mingw mode.
Perhaps you mean the ReactOS one?
I can't find it now, but I recall some discussions and Firefox trying to use it with their clang mingw builds (without much success). I must remember it wrong.
Thanks,
Jacek
-- Sincerely, Jinoh Kang
On 2/2/22 00:25, Martin Storsjö wrote:
On Tue, 1 Feb 2022, 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),
Just a minor clarification here - the above statement is true for x86_64 and aarch64; clang uses SEH on those architectures in both MSVC and mingw mode.
For i386, clang does use the MSVC exception handling mechanism in MSVC mode, but in mingw mode, it uses dwarf instead (and can use sjlj as an alternative).
For arm32, it doesn't support SEH generation at all.
ARM32 certainly supports SEH.
(In MSVC mode, it just refuses to generate unwind information,
I guess you might have mistaken; it does just fine. See: https://godbolt.org/z/h5TjsY3qe
and in mingw mode, it defaults to dwarf).
// Martin
-- Sincerely, Jinoh Kang
On Wed, 2 Feb 2022, Jinoh Kang wrote:
On 2/2/22 00:25, Martin Storsjö wrote:
On Tue, 1 Feb 2022, 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),
Just a minor clarification here - the above statement is true for x86_64 and aarch64; clang uses SEH on those architectures in both MSVC and mingw mode.
For i386, clang does use the MSVC exception handling mechanism in MSVC mode, but in mingw mode, it uses dwarf instead (and can use sjlj as an alternative).
For arm32, it doesn't support SEH generation at all.
ARM32 certainly supports SEH.
(In MSVC mode, it just refuses to generate unwind information,
I guess you might have mistaken; it does just fine.
We were talking about Clang in MSVC mode, not MSVC itself. MSVC does indeed support SEH for ARM32, but Clang doesn't support generating that, yet at least. // Martin
participants (6)
-
Bernhard Übelacker -
Jacek Caban -
Jinoh Kang -
Martin Storsjö -
Paul Gofman -
Rémi Bernon