Re: [Mingw-w64-public] [PATCH 40/40] crt: Add api-ms-win-shell-namespace-l1-1-0 to onecore_apiset
On 31/10/23 13:45, Martin Storsjö wrote: On Wed, 25 Oct 2023, Mark Harmstone wrote: Signed-off-by: Mark Harmstone --- mingw-w64-crt/Makefile.am | 1 + .../api-ms-win-shell-namespace-l1-1-0.def | 26 +++ mingw-w64-crt/lib-common/onecore_apiset.mri | 1 + .../api-ms-win-shell-namespace-l1-1-0.def | 26 +++ 4 files changed, 54 insertions(+) create mode 100644 mingw-w64-crt/lib-common/api-ms-win-shell-namespace-l1-1-0.def create mode 100644 mingw-w64-crt/lib32/api-ms-win-shell-namespace-l1-1-0.def Most of this patchset seemed good, so I pushed it. I omitted the last 4 patches. I don't find api-ms-win-core-psm-appnotify-l1-1-1, api-ms-win-net-isolation-l1-1-0, api-ms-win-net-isolation-l1-1-1 or api-ms-win-shell-namespace-l1-1-0 in any of my copies of onecore_apiset.lib from WinSDK (I checked a couple versions). // Martin Thanks Martin. Sorry, good spot - these are actually part of onecoreuap_apiset, which we don't have yet. Mark ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/3] crt: Remove duplicates in api-ms-win-core-rtlsupport
On 31/10/23 13:08, Martin Storsjö wrote: On Tue, 31 Oct 2023, Martin Storsjö wrote: On Wed, 25 Oct 2023, Mark Harmstone wrote: Signed-off-by: Mark Harmstone --- .../api-ms-win-core-rtlsupport-l1-2-0.def | 13 - ...api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def | 13 - .../lib32/api-ms-win-core-rtlsupport-l1-2-0.def | 3 --- ...api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def | 6 -- 4 files changed, 35 deletions(-) diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def b/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def index 89e8d2de1..06e121bdc 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def +++ b/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def @@ -2,16 +2,3 @@ LIBRARY api-ms-win-core-rtlsupport-l1-2-0 EXPORTS -RtlAddFunctionTable -RtlCaptureContext -RtlCaptureStackBackTrace -RtlCompareMemory -RtlDeleteFunctionTable -RtlInstallFunctionTableCallback -RtlLookupFunctionEntry -RtlPcToFileHeader -RtlRaiseException -RtlRestoreContext -RtlUnwind -RtlUnwindEx -RtlVirtualUnwind This leaves this def file entirely empty - so we should remove it. I can do that in a separate commit, otherwise these three commits look good to me. Actually - I see that the corresponding file does have symbols in the lib32 version, so we can't drop it from the dependencies or the .mri file. So I guess we'll have to keep it like this; both llvm-dlltool and GNU dlltool seem to handle this kind of dummy def file just fine. // Martin Thanks Martin. Yes, this is one of the few that's different on different architectures. Mark ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] winpthreads: Check GetModuleHandle return value before calling GetProcAddress
In Windows Store builds with the winstorecompat library,
GetModuleHandle returns null, and GetProcAddress is not documented
to allow passing null.
Signed-off-by: Martin Storsjö
---
mingw-w64-libraries/winpthreads/src/clock.c | 8 +---
mingw-w64-libraries/winpthreads/src/misc.c | 4 +++-
mingw-w64-libraries/winpthreads/src/thread.c | 6 --
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/mingw-w64-libraries/winpthreads/src/clock.c
b/mingw-w64-libraries/winpthreads/src/clock.c
index ba983c904..322b7e5c4 100644
--- a/mingw-w64-libraries/winpthreads/src/clock.c
+++ b/mingw-w64-libraries/winpthreads/src/clock.c
@@ -37,9 +37,11 @@ static GetSystemTimeAsFileTime_t GetSystemTimeAsFileTime_p
/* = 0 */;
static GetSystemTimeAsFileTime_t try_load_GetSystemPreciseTimeAsFileTime()
{
/* Use GetSystemTimePreciseAsFileTime() if available (Windows 8 or later)
*/
-GetSystemTimeAsFileTime_t get_time =
(GetSystemTimeAsFileTime_t)(intptr_t)GetProcAddress(
-GetModuleHandle ("kernel32.dll"),
-"GetSystemTimePreciseAsFileTime"); /* <1us precision on Windows 10 */
+HMODULE mod = GetModuleHandle("kernel32.dll");
+GetSystemTimeAsFileTime_t get_time = NULL;
+if (mod)
+get_time = (GetSystemTimeAsFileTime_t)(intptr_t)GetProcAddress(mod,
+"GetSystemTimePreciseAsFileTime"); /* <1us precision on Windows 10
*/
if (get_time == NULL)
get_time = GetSystemTimeAsFileTime; /* >15ms precision on Windows 10 */
__atomic_store_n(_p, get_time, __ATOMIC_RELAXED);
diff --git a/mingw-w64-libraries/winpthreads/src/misc.c
b/mingw-w64-libraries/winpthreads/src/misc.c
index 79c01f2bc..800347854 100644
--- a/mingw-w64-libraries/winpthreads/src/misc.c
+++ b/mingw-w64-libraries/winpthreads/src/misc.c
@@ -28,7 +28,9 @@ static ULONGLONG (*GetTickCount64FuncPtr) (VOID);
static void __attribute__((constructor)) ctor (void)
{
- GetTickCount64FuncPtr = (__typeof__(GetTickCount64FuncPtr))
GetProcAddress(GetModuleHandle("kernel32.dll"), "GetTickCount64");
+ HMODULE mod = GetModuleHandle("kernel32.dll");
+ if (mod)
+GetTickCount64FuncPtr = (__typeof__(GetTickCount64FuncPtr))
GetProcAddress(mod, "GetTickCount64");
}
unsigned long long _pthread_time_in_ms(void)
diff --git a/mingw-w64-libraries/winpthreads/src/thread.c
b/mingw-w64-libraries/winpthreads/src/thread.c
index 2eb76dba4..d5c2acf1f 100644
--- a/mingw-w64-libraries/winpthreads/src/thread.c
+++ b/mingw-w64-libraries/winpthreads/src/thread.c
@@ -82,8 +82,10 @@ static void __attribute__((constructor))
ctor (void)
{
HMODULE module = GetModuleHandle("kernel32.dll");
- AddVectoredExceptionHandlerFuncPtr =
(__typeof__(AddVectoredExceptionHandlerFuncPtr)) GetProcAddress(module,
"AddVectoredExceptionHandler");
- RemoveVectoredExceptionHandlerFuncPtr =
(__typeof__(RemoveVectoredExceptionHandlerFuncPtr)) GetProcAddress(module,
"RemoveVectoredExceptionHandler");
+ if (module) {
+AddVectoredExceptionHandlerFuncPtr =
(__typeof__(AddVectoredExceptionHandlerFuncPtr)) GetProcAddress(module,
"AddVectoredExceptionHandler");
+RemoveVectoredExceptionHandlerFuncPtr =
(__typeof__(RemoveVectoredExceptionHandlerFuncPtr)) GetProcAddress(module,
"RemoveVectoredExceptionHandler");
+ }
}
#endif
--
2.34.1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Mark _tls_used as used for LTO
On Tue, 31 Oct 2023, LIU Hao wrote: 在 2023-10-31 18:15, Martin Storsjö 写道: 02b4df13b1aac0dba0a35e87f1a536594fd35edd added attribute used to _CRTALLOC, applying it automatically on most such special variables that need to be retained during LTO. _tls_used is also such a variable, but it's not located in any special section; thus apply the attribute directly. Signed-off-by: Martin Storsjö --- mingw-w64-crt/crt/tlssup.c | 1 + 1 file changed, 1 insertion(+) This patch looks good to me, too. Thanks, I pushed these patches now. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.
On Tue, 31 Oct 2023, LIU Hao wrote: 在 2023-10-31 21:37, Martin Storsjö 写道: Yes, this is what I meant. The fact that Windows Store apps wouldn't be getting the modern codepath with GetTickCount64, but unconditonally be usin the old fallback codepath of using QueryPerformanceCounter, doesn't seem too bad, so I think that's acceptable. I suspect no further patch is needed? Pretty much, yeah. There is still a minor issue: When a module handle to KERNEL32 can't be obtained, we are passing a null handle to `GetProcAddress()`, which then attempts to look the target function in the current executable image, is that desired? Right - it would probably be safer/better style to check that, as I don't see it documented that it would be ok to pass a null module to GetProcAddress. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Mark _tls_used as used for LTO
在 2023-10-31 18:15, Martin Storsjö 写道: 02b4df13b1aac0dba0a35e87f1a536594fd35edd added attribute used to _CRTALLOC, applying it automatically on most such special variables that need to be retained during LTO. _tls_used is also such a variable, but it's not located in any special section; thus apply the attribute directly. Signed-off-by: Martin Storsjö --- mingw-w64-crt/crt/tlssup.c | 1 + 1 file changed, 1 insertion(+) This patch looks good to me, too. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Revert to our implementation of scalbn/scalbnf and ldexp on UCRT
在 2023-10-31 17:24, Martin Storsjö 写道: The UCRT implementation of scalbn/scalbnf (and presumably ldexp too, as it's an identical function) has a minor spec incompliance; it doesn't respect the rounding mode that has been set. For most uses of scalbn, rounding isn't at play at all; rounding only makes a difference when scaling the floats out of range, for deciding between staying at DBL_MAX or going to infinity, or likewise between the smallest subnormal or going to zero. This is observed in compiler-rt's testsuite for builtins. Signed-off-by: Martin Storsjö --- I submitted a PR to change compiler-rt's tests to ignore this failure at https://github.com/llvm/llvm-project/pull/70776 as well, but if we consider strictness in these corner cases important enough we can certainly do this revert as well. --- mingw-w64-crt/Makefile.am | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) This patch looks good to me. Thanks. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.
在 2023-10-31 21:37, Martin Storsjö 写道: Yes, this is what I meant. The fact that Windows Store apps wouldn't be getting the modern codepath with GetTickCount64, but unconditonally be usin the old fallback codepath of using QueryPerformanceCounter, doesn't seem too bad, so I think that's acceptable. I suspect no further patch is needed? There is still a minor issue: When a module handle to KERNEL32 can't be obtained, we are passing a null handle to `GetProcAddress()`, which then attempts to look the target function in the current executable image, is that desired? -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 40/40] crt: Add api-ms-win-shell-namespace-l1-1-0 to onecore_apiset
On Wed, 25 Oct 2023, Mark Harmstone wrote: Signed-off-by: Mark Harmstone --- mingw-w64-crt/Makefile.am | 1 + .../api-ms-win-shell-namespace-l1-1-0.def | 26 +++ mingw-w64-crt/lib-common/onecore_apiset.mri | 1 + .../api-ms-win-shell-namespace-l1-1-0.def | 26 +++ 4 files changed, 54 insertions(+) create mode 100644 mingw-w64-crt/lib-common/api-ms-win-shell-namespace-l1-1-0.def create mode 100644 mingw-w64-crt/lib32/api-ms-win-shell-namespace-l1-1-0.def Most of this patchset seemed good, so I pushed it. I omitted the last 4 patches. I don't find api-ms-win-core-psm-appnotify-l1-1-1, api-ms-win-net-isolation-l1-1-0, api-ms-win-net-isolation-l1-1-1 or api-ms-win-shell-namespace-l1-1-0 in any of my copies of onecore_apiset.lib from WinSDK (I checked a couple versions). // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.
On Tue, 31 Oct 2023, LIU Hao wrote: 在 2023/10/31 16:20, Martin Storsjö 写道: Right. On the other hand, the QueryPerformanceCounter based fallback implementation probably is workable enough for winstore apps as well, I would guess, so perhaps it't not worth making a fuss about in the end anyway. The issue is not about whether there is a fallback; the issue is about when to use the fallback. If we still aim at providing a (static) winpthreads that is eligible for Windows Store apps, then there does not seem any way to detect the existence of `GetTickCount64()`, and as a consequence we would have to use the fallback unconditionally. We also notice that `QueryPerformanceCounter()` is quite fast on modern Windows; the frequency is probably not but that variable isn't gonna change hence can be static anyway. Yes, this is what I meant. The fact that Windows Store apps wouldn't be getting the modern codepath with GetTickCount64, but unconditonally be usin the old fallback codepath of using QueryPerformanceCounter, doesn't seem too bad, so I think that's acceptable. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.
在 2023/10/31 16:20, Martin Storsjö 写道: Right. On the other hand, the QueryPerformanceCounter based fallback implementation probably is workable enough for winstore apps as well, I would guess, so perhaps it't not worth making a fuss about in the end anyway. The issue is not about whether there is a fallback; the issue is about when to use the fallback. If we still aim at providing a (static) winpthreads that is eligible for Windows Store apps, then there does not seem any way to detect the existence of `GetTickCount64()`, and as a consequence we would have to use the fallback unconditionally. We also notice that `QueryPerformanceCounter()` is quite fast on modern Windows; the frequency is probably not but that variable isn't gonna change hence can be static anyway. -- Best regards, LIU Hao OpenPGP_signature Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Remove MapViewOfFile3 and VirtualAlloc2 from api-ms-win-core-memory-l1-1-6 in windowsapp
On Wed, 25 Oct 2023, Mark Harmstone wrote: Signed-off-by: Mark Harmstone --- mingw-w64-crt/Makefile.am | 2 +- .../lib-common/api-ms-win-core-memory-l1-1-6_windowsapp.def | 6 ++ mingw-w64-crt/lib-common/windowsapp.mri | 2 +- .../lib32/api-ms-win-core-memory-l1-1-6_windowsapp.def | 6 ++ 4 files changed, 14 insertions(+), 2 deletions(-) create mode 100644 mingw-w64-crt/lib-common/api-ms-win-core-memory-l1-1-6_windowsapp.def create mode 100644 mingw-w64-crt/lib32/api-ms-win-core-memory-l1-1-6_windowsapp.def These sets of patches looked good, and reduce the diff to WinSDK mincore/windowsapp libraries, so I went ahead and pushed them. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/3] crt: Remove duplicates in api-ms-win-core-rtlsupport
On Tue, 31 Oct 2023, Martin Storsjö wrote: On Wed, 25 Oct 2023, Mark Harmstone wrote: Signed-off-by: Mark Harmstone --- .../api-ms-win-core-rtlsupport-l1-2-0.def | 13 - ...api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def | 13 - .../lib32/api-ms-win-core-rtlsupport-l1-2-0.def | 3 --- ...api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def | 6 -- 4 files changed, 35 deletions(-) diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def b/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def index 89e8d2de1..06e121bdc 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def +++ b/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def @@ -2,16 +2,3 @@ LIBRARY api-ms-win-core-rtlsupport-l1-2-0 EXPORTS -RtlAddFunctionTable -RtlCaptureContext -RtlCaptureStackBackTrace -RtlCompareMemory -RtlDeleteFunctionTable -RtlInstallFunctionTableCallback -RtlLookupFunctionEntry -RtlPcToFileHeader -RtlRaiseException -RtlRestoreContext -RtlUnwind -RtlUnwindEx -RtlVirtualUnwind This leaves this def file entirely empty - so we should remove it. I can do that in a separate commit, otherwise these three commits look good to me. Actually - I see that the corresponding file does have symbols in the lib32 version, so we can't drop it from the dependencies or the .mri file. So I guess we'll have to keep it like this; both llvm-dlltool and GNU dlltool seem to handle this kind of dummy def file just fine. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/3] crt: Remove duplicates in api-ms-win-core-rtlsupport
On Wed, 25 Oct 2023, Mark Harmstone wrote: Signed-off-by: Mark Harmstone --- .../api-ms-win-core-rtlsupport-l1-2-0.def | 13 - ...api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def | 13 - .../lib32/api-ms-win-core-rtlsupport-l1-2-0.def | 3 --- ...api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def | 6 -- 4 files changed, 35 deletions(-) diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def b/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def index 89e8d2de1..06e121bdc 100644 --- a/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def +++ b/mingw-w64-crt/lib-common/api-ms-win-core-rtlsupport-l1-2-0_windowsapp.def @@ -2,16 +2,3 @@ LIBRARY api-ms-win-core-rtlsupport-l1-2-0 EXPORTS -RtlAddFunctionTable -RtlCaptureContext -RtlCaptureStackBackTrace -RtlCompareMemory -RtlDeleteFunctionTable -RtlInstallFunctionTableCallback -RtlLookupFunctionEntry -RtlPcToFileHeader -RtlRaiseException -RtlRestoreContext -RtlUnwind -RtlUnwindEx -RtlVirtualUnwind This leaves this def file entirely empty - so we should remove it. I can do that in a separate commit, otherwise these three commits look good to me. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] crt: Mark __guard_dispatch_icall_dummy as global
Seems reasonable to me, thanks for checking.
On 31/10/2023 18:14, Martin Storsjö wrote:
In LLVM LTO builds with cfguard enabled, the non-extern
__guard_dispatch_icall_dummy can't pose as replacement for the
undefined symbol reference to an extern __guard_dispatch_icall_dummy.
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/cfguard/mingw_cfguard_support.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-crt/cfguard/mingw_cfguard_support.c
b/mingw-w64-crt/cfguard/mingw_cfguard_support.c
index cf4535afd..1e777ebfc 100644
--- a/mingw-w64-crt/cfguard/mingw_cfguard_support.c
+++ b/mingw-w64-crt/cfguard/mingw_cfguard_support.c
@@ -20,6 +20,7 @@ static void __guard_check_icall_dummy(void) {}
// When CFGuard is not active, directly tail-call the target address, which
// is passed via %rax.
__asm__(
+".globl __guard_dispatch_icall_dummy\n"
"__guard_dispatch_icall_dummy:\n"
"jmp *%rax\n"
);
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] crt: Mark _tls_used as used for LTO
02b4df13b1aac0dba0a35e87f1a536594fd35edd added attribute used to
_CRTALLOC, applying it automatically on most such special variables
that need to be retained during LTO. _tls_used is also such a variable,
but it's not located in any special section; thus apply the attribute
directly.
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/crt/tlssup.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-crt/crt/tlssup.c b/mingw-w64-crt/crt/tlssup.c
index 47beb27fc..1b9d7b4a0 100644
--- a/mingw-w64-crt/crt/tlssup.c
+++ b/mingw-w64-crt/crt/tlssup.c
@@ -44,6 +44,7 @@ _CRTALLOC(".tls$ZZZ") char *_tls_end = NULL;
_CRTALLOC(".CRT$XLA") PIMAGE_TLS_CALLBACK __xl_a = 0;
_CRTALLOC(".CRT$XLZ") PIMAGE_TLS_CALLBACK __xl_z = 0;
+__attribute__((used))
const IMAGE_TLS_DIRECTORY _tls_used = {
(ULONG_PTR) &_tls_start, (ULONG_PTR) &_tls_end,
(ULONG_PTR) &_tls_index, (ULONG_PTR) (&__xl_a+1),
--
2.34.1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] crt: Mark __guard_dispatch_icall_dummy as global
In LLVM LTO builds with cfguard enabled, the non-extern
__guard_dispatch_icall_dummy can't pose as replacement for the
undefined symbol reference to an extern __guard_dispatch_icall_dummy.
Signed-off-by: Martin Storsjö
---
mingw-w64-crt/cfguard/mingw_cfguard_support.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mingw-w64-crt/cfguard/mingw_cfguard_support.c
b/mingw-w64-crt/cfguard/mingw_cfguard_support.c
index cf4535afd..1e777ebfc 100644
--- a/mingw-w64-crt/cfguard/mingw_cfguard_support.c
+++ b/mingw-w64-crt/cfguard/mingw_cfguard_support.c
@@ -20,6 +20,7 @@ static void __guard_check_icall_dummy(void) {}
// When CFGuard is not active, directly tail-call the target address, which
// is passed via %rax.
__asm__(
+".globl __guard_dispatch_icall_dummy\n"
"__guard_dispatch_icall_dummy:\n"
"jmp *%rax\n"
);
--
2.34.1
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] crt: Revert to our implementation of scalbn/scalbnf and ldexp on UCRT
The UCRT implementation of scalbn/scalbnf (and presumably ldexp too, as it's an identical function) has a minor spec incompliance; it doesn't respect the rounding mode that has been set. For most uses of scalbn, rounding isn't at play at all; rounding only makes a difference when scaling the floats out of range, for deciding between staying at DBL_MAX or going to infinity, or likewise between the smallest subnormal or going to zero. This is observed in compiler-rt's testsuite for builtins. Signed-off-by: Martin Storsjö --- I submitted a PR to change compiler-rt's tests to ignore this failure at https://github.com/llvm/llvm-project/pull/70776 as well, but if we consider strictness in these corner cases important enough we can certainly do this revert as well. --- mingw-w64-crt/Makefile.am | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/mingw-w64-crt/Makefile.am b/mingw-w64-crt/Makefile.am index d94461c00..833c392b0 100644 --- a/mingw-w64-crt/Makefile.am +++ b/mingw-w64-crt/Makefile.am @@ -216,7 +216,6 @@ src_msvcrt_common_add_x86=\ math/x86/floor.S \ math/x86/fmod.c \ math/x86/ilogb.S math/x86/ilogbf.S \ - math/x86/ldexp.c \ math/x86/log.c \ math/x86/log1p.S math/x86/log1pf.S \ math/x86/log2.S math/x86/log2f.S \ @@ -226,7 +225,6 @@ src_msvcrt_common_add_x86=\ math/x86/remainder.S math/x86/remainderf.S \ math/x86/remquo.S math/x86/remquof.S \ math/x86/rint.c math/x86/rintf.c \ - math/x86/scalbn.S math/x86/scalbnf.S \ math/x86/sin.c \ math/x86/trunc.S math/x86/truncf.S \ \ @@ -786,10 +784,13 @@ src_libmingwex_x86=\ math/x86/exp2l.S math/x86/exp.def.hmath/x86/expl.c math/x86/expm1.def.h math/x86/expm1l.c \ math/x86/fastmath.h math/x86/floorl.S \ math/x86/fmodl.c math/x86/fucom.c \ - math/x86/ilogbl.S math/x86/internal_logl.S math/x86/ldexpl.c \ + math/x86/ilogbl.S math/x86/internal_logl.S \ + math/x86/ldexp.c math/x86/ldexpl.c \ math/x86/log.def.hmath/x86/log10l.S math/x86/log1pl.S math/x86/log2l.S \ math/x86/logbl.c math/x86/logl.c math/x86/nearbyintl.S math/x86/pow.def.hmath/x86/powl.c \ - math/x86/remainderl.S math/x86/remquol.Smath/x86/scalbnl.S math/x86/sin.def.h\ + math/x86/remainderl.S math/x86/remquol.S\ + math/x86/scalbn.S math/x86/scalbnf.Smath/x86/scalbnl.S \ + math/x86/sin.def.h\ math/x86/sinl.c math/x86/sinl_internal.S math/x86/tanl.S -- 2.34.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winpthreads: change LoadLibrary calls to GetModuleHandle after cb7f42e.
On Tue, 31 Oct 2023, Jacek Caban wrote: I find the claim that it's fine to wait for longer to be questionable. GetTickCount's value may be off by up to 16 ms, so the way elapsed time is calculated in those helpers may be off by up to 32 ms. I guess that precise waits matter mostly for short timeouts in scenarios where timeouts are semi-expected to happen and then the overhead of over-waiting may be not negligible. I wonder if the observed too short waits are an effect of measurements problems in tests, but I can't judge on that without seeing tests. All operating systems will have some sort of accuracy considerations in this area and kernel is in a better position to handle it than we are. Anyway, I realize that a revert to be controversial and don't intend to insist. Playing with plain GetTickCount is probably worth a try, through. Right. On the other hand, the QueryPerformanceCounter based fallback implementation probably is workable enough for winstore apps as well, I would guess, so perhaps it't not worth making a fuss about in the end anyway. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
