I used the following test program (compiled with MSVC with /MD):
``` #include <windows.h> #include <stdio.h>
typedef void** (__cdecl *pcurrent_exception)(void);
int main() { HMODULE hvcr = LoadLibraryA("vcruntime140.dll"); HMODULE ucrtb = LoadLibraryA("ucrtbase.dll"); pcurrent_exception p__current_exception1, p__current_exception2;
p__current_exception1 = (pcurrent_exception)GetProcAddress(hvcr, "__current_exception"); p__current_exception2 = (pcurrent_exception)GetProcAddress(ucrtb, "__current_exception");
try { throw("ex1"); } catch (const char *s) { EXCEPTION_RECORD* rec1 = (EXCEPTION_RECORD *)*p__current_exception1(); EXCEPTION_RECORD* rec2 = (EXCEPTION_RECORD *)*p__current_exception2();
printf("Exception %s, rec1 %p (code %#lx), rec2 %p.\n", s, rec1, rec1->ExceptionCode, rec2); } } ``` This outputs the following on Windows: ``` Exception ex1, rec1 00000089CAF9F990 (code 0xe06d7363), rec2 0000000000000000. ```
So I think that confirms that: 1. vcruntime140 and ucrtbase have distinct local data (or at least current exception data) on Windows; 2. vcruntime140_1 links to vcruntime140. 3. msvcp140 should link to vcruntime140's exception data too as it is apparently able to get the correct current exception in ?__ExceptionPtrCurrentException@@YAXPEAX@Z.
These patches allow the current exception to be correctly located when there are mixed builtin and native VC runtime 140.
From: Paul Gofman pgofman@codeweavers.com
--- dlls/vcruntime140/Makefile.in | 1 + dlls/vcruntime140_1/Makefile.in | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/dlls/vcruntime140/Makefile.in b/dlls/vcruntime140/Makefile.in index 2b4d6af7c91..b09faf2c901 100644 --- a/dlls/vcruntime140/Makefile.in +++ b/dlls/vcruntime140/Makefile.in @@ -1,4 +1,5 @@ MODULE = vcruntime140.dll +IMPORTLIB = vcruntime140
C_SRCS = \ misc.c diff --git a/dlls/vcruntime140_1/Makefile.in b/dlls/vcruntime140_1/Makefile.in index 31f15af2989..6b76e4576bc 100644 --- a/dlls/vcruntime140_1/Makefile.in +++ b/dlls/vcruntime140_1/Makefile.in @@ -1,4 +1,5 @@ -MODULE = vcruntime140_1.dll +MODULE = vcruntime140_1.dll +IMPORTS = vcruntime140
C_SRCS = \ except_x86_64.c
From: Paul Gofman pgofman@codeweavers.com
--- dlls/msvcp140/Makefile.in | 1 + 1 file changed, 1 insertion(+)
diff --git a/dlls/msvcp140/Makefile.in b/dlls/msvcp140/Makefile.in index eb0c8c3ef39..c5b1582944b 100644 --- a/dlls/msvcp140/Makefile.in +++ b/dlls/msvcp140/Makefile.in @@ -2,6 +2,7 @@ MODULE = msvcp140.dll EXTRADEFS = -D_MSVCP_VER=140 PARENTSRC = ../msvcp90 IMPORTLIB = msvcp140 +IMPORTS = vcruntime140
C_SRCS = \ details.c \
Hi,
It looks like your patch introduced the new failures shown below. Please investigate and fix them before resubmitting your patch. If they are not new, fixing them anyway would help a lot. Otherwise please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=124933
Your paranoid android.
=== debian11 (build log) ===
Use of uninitialized value $Flaky in addition (+) at /home/testbot/lib/WineTestBot/LogUtils.pm line 720, <$LogFile> line 24693. Use of uninitialized value $Flaky in addition (+) at /home/testbot/lib/WineTestBot/LogUtils.pm line 720, <$LogFile> line 24693. Use of uninitialized value $Flaky in addition (+) at /home/testbot/lib/WineTestBot/LogUtils.pm line 720, <$LogFile> line 24693.
We would need something similar in msvcp140_1, msvcp140_2 and msvcp140_atomic_wait dlls in future (but there are no imports from vcruntime140 currently). It would be also good to stop forwarding to ucrtbase in vcruntime140 but the code will need to be restructured to do it properly.
This merge request was approved by Piotr Caban.