Re: [Mingw-w64-public] [PATCH] crt: Fix building LTO version of mingw-w64 crt libraries
在 2022-12-24 06:14, Pali Rohár 写道:
I just quickly tested it only in wine. Without LTO it prints "ł$"
(really strange, looks like some memory problem, maybe in wine?).
Oops, sorry forgot that the callback for `__cxa_thread_atexit` should be specified with `__cdecl`,
otherwise its argument (the second argument for `__cxa_thread_atexit`) will be passed incorrectly on
i686.
This can be rectified like this:
```
typedef void __thiscall atexit_func(void*);
extern int __cxa_thread_atexit(atexit_func*, void*, void*);
extern void* __dso_handle;
extern int puts(const char*);
void
__thiscall
puts_wrapper(void* param)
{
puts(param);
}
int
main(void)
{
/* print a string upon the current thread's exit. */
__cxa_thread_atexit(puts_wrapper, "test thread atexit",
&__dso_handle);
}
```
And with LTO it prints nothing. When I added __attribute__((used)) for
those 3 symbols then it started printing "ő<".
So the attribute seems necessary. Patches are welcome.
--
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] headers: Use Windows 10 as default _WIN32_WINNT value.
On Sat, 24 Dec 2022, LIU Hao wrote: > The only issue in this thread seems to be inside GNU lib because it relies on > the default value. That's probably not good; however, given GNU lib users are > less likely to be aware of this Windows-specific macro, maybe we can propose > GNU lib should set a default, safer value, if no one is given elsewhere. BTW I > do think that `_WIN32_WINNT` should always be set when compiling Windows code. Not just gnulib, but llvm's libc++ as well. There was discussion about possibly defining _WIN32_WINNT during libc++ build to win7 to allow the packaged binaries to continue to work there, but I don't know if there was a decision to do that, revert the default to win7, or just accept that our libc++ binaries won't work on win7 anymore. (I don't care at all about win 8.0, I don't know if anyone else does...) ___ 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: Fix building LTO version of mingw-w64 crt libraries
On Saturday 24 December 2022 03:17:57 LIU Hao wrote:
> 在 2022-12-24 01:43, Pali Rohár 写道:
> > Ou right. They would also require __attribute__((used)) for LTO builds.
> > I just tested simple single process/thread console applications and they
> > worked.
> >
> > Do you have any test case application which would be affected if these
> > symbols are eliminated?
>
> Does this program still have an output, with LTO?
>
> ```
> typedef void atexit_func(void*);
> extern int __cxa_thread_atexit(atexit_func*, void*, void*);
> extern void* __dso_handle;
> extern int puts(const char*);
>
> int
> main(void)
> {
> /* print a string upon the current thread's exit. */
> __cxa_thread_atexit((atexit_func*) puts, "test thread atexit",
> &__dso_handle);
> }
> ```
>
> This attempts to call the `__cxa_thread_atexit` from mingw-w64 CRT instead
> of the one provided by libgcc. If TLS facilities are optimized out then
> there will be no output.
I just quickly tested it only in wine. Without LTO it prints "ł$"
(really strange, looks like some memory problem, maybe in wine?).
And with LTO it prints nothing. When I added __attribute__((used)) for
those 3 symbols then it started printing "ő<".
___
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] headers: Use Windows 10 as default _WIN32_WINNT value.
在 2022-12-24 01:48, Jeremy Drake via Mingw-w64-public 写道: I recently discovered that llvm's libc++ has something similar. MSYS2 recently bumped their default _WIN32_WINNT to Windows 8.1, and the libc++ built after that no longer worked on Windows 7. I was of the understanding that that macro was intended to be set by project code, and just controlled what APIs were made available by the headers, and the project code could simply not call anything from a newer version. But it seems that some projects treat it instead as telling *them* what APIs they can call, and that results in it being a minimum supported OS version. I didn't know MS explicitly called it out as such in a doc somewhere. For MSYS2 I think that's probably desired. People who set `_WIN32_WINNT` to a specific version should be supposed to be requesting some APIs of that version. If there are newer and better APIs why not use them? There's nothing wrong with that. The commit that bumped the default value of `_WIN32_WINNT` was an attempt to match Windows SDK. There's nothing wrong with that, either. The only issue in this thread seems to be inside GNU lib because it relies on the default value. That's probably not good; however, given GNU lib users are less likely to be aware of this Windows-specific macro, maybe we can propose GNU lib should set a default, safer value, if no one is given elsewhere. BTW I do think that `_WIN32_WINNT` should always be set when compiling Windows code. -- 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: Fix building LTO version of mingw-w64 crt libraries
在 2022-12-24 01:43, Pali Rohár 写道:
Ou right. They would also require __attribute__((used)) for LTO builds.
I just tested simple single process/thread console applications and they
worked.
Do you have any test case application which would be affected if these
symbols are eliminated?
Does this program still have an output, with LTO?
```
typedef void atexit_func(void*);
extern int __cxa_thread_atexit(atexit_func*, void*, void*);
extern void* __dso_handle;
extern int puts(const char*);
int
main(void)
{
/* print a string upon the current thread's exit. */
__cxa_thread_atexit((atexit_func*) puts, "test thread atexit",
&__dso_handle);
}
```
This attempts to call the `__cxa_thread_atexit` from mingw-w64 CRT instead of the one provided by
libgcc. If TLS facilities are optimized out then there will be no output.
--
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] headers: Use Windows 10 as default _WIN32_WINNT value.
On Fri, 23 Dec 2022, Roger Pack wrote: > Ran into this. > According to > https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170 > "The preprocessor macros WINVER and _WIN32_WINNT specify the minimum > operating system version your code supports." > > Anyway, setting this value to default to windows 10 caught me > recently, suddenly compiling gnutls doesn't work for windows 7 anymore > It uses Gnulib's gettimeofday.c internally, which links against the > windows 8' GetSystemTimePreciseAsFileTime if _WIN32_WINNT is set high > enough. I recently discovered that llvm's libc++ has something similar. MSYS2 recently bumped their default _WIN32_WINNT to Windows 8.1, and the libc++ built after that no longer worked on Windows 7. I was of the understanding that that macro was intended to be set by project code, and just controlled what APIs were made available by the headers, and the project code could simply not call anything from a newer version. But it seems that some projects treat it instead as telling *them* what APIs they can call, and that results in it being a minimum supported OS version. I didn't know MS explicitly called it out as such in a doc somewhere. ___ 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: Fix building LTO version of mingw-w64 crt libraries
On Saturday 24 December 2022 01:00:59 LIU Hao wrote: > 在 2022-12-24 00:18, Pali Rohár 写道: > > What is the reason? Maybe it was gcc/ld bug which this patch workarounds? > > > > Generally speaking, all variables that are required to be placed in special > sections to take effect, but are not otherwise referenced, are likely to be > affected by LTO, and have to be tested carefully. At the moment, these are > `__xl_b`, `__xl_c` and `_tls_used`, but there might be more. Ou right. They would also require __attribute__((used)) for LTO builds. I just tested simple single process/thread console applications and they worked. Do you have any test case application which would be affected if these symbols are eliminated? ___ 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: Fix building LTO version of mingw-w64 crt libraries
在 2022-12-24 00:18, Pali Rohár 写道: What is the reason? Maybe it was gcc/ld bug which this patch workarounds? Generally speaking, all variables that are required to be placed in special sections to take effect, but are not otherwise referenced, are likely to be affected by LTO, and have to be tested carefully. At the moment, these are `__xl_b`, `__xl_c` and `_tls_used`, but there might be more. -- 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 1/3] crt: Add non-inline variant of UCRT _scprintf, _snprintf and _snscanf functions
On Friday 23 December 2022 22:20:25 LIU Hao wrote: > 在 2022-12-04 21:49, Pali Rohár 写道: > > Format attributes is interesting issue. Because there are already following > > printf implementations: > > > > 1) C89 (without %lld) (crtdll.dll, msvcrt10.dll) > > 2) C89 (without %lld) + MS extensions %I64d (msvcrt20.dll - msvcr110.dll) > > 3) C99 (with %lld) + MS extensions %I64d (msvcr120.dll, vcruntime140.dll) > > 4) C99 (with %lld) + GNU extensions (this is what glibc has) > > 5) C99 (with %lld) + MS extensions + GNU extensions (mingw-w64 pformat.c) > > > > This is not 100% correct. The MS printf specification never conforms to the > C99 standard: > > 1) `%hhd` expects a `short` instead of `signed char`, verified with >MSVCR120 and MSVCRT on Win10. > 2) `%zd`, `%td`, `%jd` are all unsupported up to MSVCR120, which, >however, MSVCRT on Win10 seems to support. > 3) `%Lg` matches `long double` in MS ABI i.e. the same with `double`. Thanks for information! It just means that we have more than above 5 printf versions widely used. > I don't think it's practically possible to provide unified non-inline *printf > functions. Why not? How inline and non-inline differs here? The issue is with format attribute, but because gcc does not provide all 8 versions mentioned here, it just means that both inline and non-inline versions have same issues. ___ 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: Fix building LTO version of mingw-w64 crt libraries
On Friday 23 December 2022 22:25:57 LIU Hao wrote: > 在 2022-12-21 21:00, Martin Storsjö 写道: > > > > I believe this patch should be harmless; for regular object file based > > linking, __attribute__((used)) shouldn't have any effect across object > > file boundaries (it only affects what's emitted and what's optimized out > > from within each object file). And for LTO linking, the linking stage > > would still pull in the same set of LTO object files from the static > > libraries, and this only affects what symbols get emitted from the LTO > > code generation step. > > > > So I would be fine with this patch - although I guess I could include it > > in a test build run with Clang/LLD. > > > > I guess I'd need to build mingw-w64-crt with -flto in order to reproduce > > the situation at hand though. I don't currently have a test setup where > > I do that (but iirc Zig builds mingw-w64-crt that way, with optional > > LTO). > > > > I thought I was told that the CRT shouldn't be built with `-flto`... What is the reason? Maybe it was gcc/ld bug which this patch workarounds? > This patch shouldn't affect non-LTO builds, so pushed for now. If there are > any issues, please let me know. Yes, it should not affect non-LTO builds. Thanks! ___ 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: Fix building LTO version of mingw-w64 crt libraries
在 2022-12-21 21:00, Martin Storsjö 写道: I believe this patch should be harmless; for regular object file based linking, __attribute__((used)) shouldn't have any effect across object file boundaries (it only affects what's emitted and what's optimized out from within each object file). And for LTO linking, the linking stage would still pull in the same set of LTO object files from the static libraries, and this only affects what symbols get emitted from the LTO code generation step. So I would be fine with this patch - although I guess I could include it in a test build run with Clang/LLD. I guess I'd need to build mingw-w64-crt with -flto in order to reproduce the situation at hand though. I don't currently have a test setup where I do that (but iirc Zig builds mingw-w64-crt that way, with optional LTO). I thought I was told that the CRT shouldn't be built with `-flto`... This patch shouldn't affect non-LTO builds, so pushed for now. If there are any issues, please let me know. -- 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 1/3] crt: Add non-inline variant of UCRT _scprintf, _snprintf and _snscanf functions
在 2022-12-04 21:49, Pali Rohár 写道: Format attributes is interesting issue. Because there are already following printf implementations: 1) C89 (without %lld) (crtdll.dll, msvcrt10.dll) 2) C89 (without %lld) + MS extensions %I64d (msvcrt20.dll - msvcr110.dll) 3) C99 (with %lld) + MS extensions %I64d (msvcr120.dll, vcruntime140.dll) 4) C99 (with %lld) + GNU extensions (this is what glibc has) 5) C99 (with %lld) + MS extensions + GNU extensions (mingw-w64 pformat.c) This is not 100% correct. The MS printf specification never conforms to the C99 standard: 1) `%hhd` expects a `short` instead of `signed char`, verified with MSVCR120 and MSVCRT on Win10. 2) `%zd`, `%td`, `%jd` are all unsupported up to MSVCR120, which, however, MSVCRT on Win10 seems to support. 3) `%Lg` matches `long double` in MS ABI i.e. the same with `double`. I don't think it's practically possible to provide unified non-inline *printf functions. -- 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] genstubdll: Remove
在 2022-12-22 02:04, Jacek Caban 写道: Removal seems good to me. Thanks. Pushed to master now. -- 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] headers: Use Windows 10 as default _WIN32_WINNT value.
On Sat, Dec 26, 2020 at 6:41 AM Jacek Caban wrote: > > Signed-off-by: Jacek Caban > --- > > I think it's reasonable to assume that the current default value of > Windows XP does not reflect reality. The new value deserves some > considerations. I propose to go all the way to Windows 10 and match > Windows SDK. > > The main concern about this is compatibility. This value is commonly > mistaken with 'minimum version supported in runtime', which is simply > not the case. It's only a version that headers will provide declarations > for. As long as the application does not use new APIs, its compatibility > with older Windows will not change. > > I think that the change reflects expectations of majority of users. If > users still want headers to not provide Win10-only declarations, they > may just set _WIN32_WINNT explicitly in build system to the exact > version they want. If packagers prefer it the old way, they can use the > configure stitch for that. Ran into this. According to https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170 "The preprocessor macros WINVER and _WIN32_WINNT specify the minimum operating system version your code supports." Anyway, setting this value to default to windows 10 caught me recently, suddenly compiling gnutls doesn't work for windows 7 anymore It uses Gnulib's gettimeofday.c internally, which links against the windows 8' GetSystemTimePreciseAsFileTime if _WIN32_WINNT is set high enough. You can manually set CFLAGS=_WIN32_WINNT... but some libraries don't realize that and now everywhere that wants to support 7 is forced to set it. Just a thought. If you're comfortable basically having every package everywhere that supports windows < 10 to specify it I guess that's an option. Cheers! ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
