Re: [Mingw-w64-public] [PATCH] headers: Add tcpxcv.h
在 2024-04-23 15:42, Biswapriyo Nath 写道: From fe72cdf89cd2d583c3fa4c43406fc08777bc1fe5 Mon Sep 17 00:00:00 2001 From: Biswapriyo Nath Date: Tue, 23 Apr 2024 07:41:17 + Subject: [PATCH] headers: Add tcpxcv.h Fixeshttps://github.com/mingw-w64/mingw-w64/issues/46 Signed-off-by: Biswapriyo Nath --- mingw-w64-headers/include/tcpxcv.h | 92 ++ 1 file changed, 92 insertions(+) create mode 100644 mingw-w64-headers/include/tcpxcv.h Thanks for the patch. Pushed to master now. -- Best regards, LIU Hao OpenPGP_signature.asc 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 10/10] crt: Move find, stat and time aliases to def-include/msvcrt-common.def.in
On Thursday 25 April 2024 23:41:24 Martin Storsjö wrote: > On Thu, 25 Apr 2024, Pali Rohár wrote: > > > On Wednesday 24 April 2024 23:41:24 Martin Storsjö wrote: > > > On Mon, 22 Apr 2024, Pali Rohár wrote: > > > > > > > diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in > > > > b/mingw-w64-crt/lib-common/ucrtbase.def.in > > > > index 2d0552f277ef..c8fb1e33b1d7 100644 > > > > --- a/mingw-w64-crt/lib-common/ucrtbase.def.in > > > > +++ b/mingw-w64-crt/lib-common/ucrtbase.def.in > > > > @@ -327,12 +327,10 @@ _filelength > > > > _filelengthi64 > > > > _fileno > > > > _findclose > > > > -_findfirst == _findfirst64 > > > > > > Note how we unconditionally had these macros pointing at _findfirst64 in > > > ucrt, regardless of architecture. > > > > I must admit that this is an interesting issue. > > > > I looked at the mingw-w64-headers/crt/io.h file now and it is not set > > unconditionally as you wrote. > > I didn't say that the headers unconditionally uses it this way. I just said > that the exist, most probably buggy, def file line right above what I > quoted, unconditionally does "_findfirst == _findfirst64" for all > architectures. > > Yes it's probably wrong - but we shouldn't be changing it in a refactoring > patch, that's all I tried to say here. > > > Anyway, this def file defines symbol alias "_findfirst" for linking. And > > every c/c++ source file which includes headers files would result in > > object file which will use either "_findfirst32" or "_findfirst64i32". > > Not "_findfirst" symbol. So in my opinion, this change should be safe. > > It may very well be safe in practice, but I don't want such a subtle, > unannounced change buried in a patch that refactors many hundreds of lines, > where the rest mostly is a pure refactoring. Yes, of course, I mean to put all such changes in separate patch. > > I think that meaning of the symbols should be same independently of the > > used CRT library. And for me this looks like a bug that UCRT was > > resolving _findfirst to different ABI function than msvcrt, at link > > time. > > I disagree here. UCRT has a different ABI than msvcrt, overall, with time_t > defaulting to 64 bit on UCRT on 32 bit platforms, contrary to msvcrt. ABI for ucrt and msvcrt is different, but what I see is that symbols which are in both libraries use same times. ucrt DLL libraries do not have _findfirst symbol. They have only symbols with suffixes (32, 64, 32i64 and 64i32). And those symbols with these suffixes are present in new msvcrt versions and have same meaning. As using "_findfirst" symbol directly (without any suffix) is not so common, and it is not available in UCRT at all, I would propose to define it to the same time_t bit length as in msvcrt. It would simplify symbol definitions as it would have always just one meaning (for 32-bit). And also it would allow to create object file which calls "_findfirst" symbol and then link it with any mingw-w64 CRT import library. I think it is better to have stable symbol meaning than to have symbol alias matching what the headers default to. Stable symbol meaning can be an invariant in this case. But symbol matching with header file is not stable as application can change it by -D_USE_32BIT_TIME_T. What do you think? Does it make sense? > I think the default symbol here should match what the headers default to, > when used in a UCRT configuration. > > > I guess that it was rare to hit this issue as it required to either not > > include mingw-w64 header files and declare functions manually. Or write > > application in other language which does not use mingw-w64 C header > > files (e.g. in assembly or something similar) but uses mingw-w64 CRT > > libraries for linking. > > Yes, this is not something that would be encountered often in practice, I > agree with that. > > > Please check what I wrote above. If you agree that this is a bug, I can > > prepare a separate fix for the UCRT (and then rebase 10/10 on top of > > it). > > I agree that the current state probably is a bug. > > As the headers default to 64 bit time_t, then _findfirst should probably > resolve to _findfirst64i32, for both 32 and 64 bit. Similarly for the other > symbols. > > That's most probably my original intent in how I set these up - that we > point at the "64 bit version", but I missed that it really is > _findfirst64i32 and not _findfirst64. > > I'd appreciate a patch that fixes these aliases, consistently for > ucrtbase.def.in and the api-ms-win-crt-*.def.in, and then we can rebase > patch 10/10 on top of it, where I'd expect no changes in the preprocessed > output of the ucrt def files. Yes, I agree. > > Ou, and another files for which I forget api-ms-win-crt-*.def.in. And > > this is because they do not include that common .def.in file. > > > > I can look at them, but I would prefer to do it after all existing stuff > > is resolved as basically api-ms-win-crt-*.def.in does not use any common > > aliases. > > > > In my opinion, it
Re: [Mingw-w64-public] [PATCH 5/5] headers: Stop using the __mingw_static_ovr macro
On Thu, 25 Apr 2024, Jacek Caban wrote: Patches look good to me. Thanks! I'll go ahead and push them then. // 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 00/10] crt: Move symbol aliases from CRT def files to msvcrt-common.def.in
On Thu, 25 Apr 2024, Pali Rohár wrote: On Thursday 25 April 2024 20:18:44 Pali Rohár wrote: On Wednesday 24 April 2024 23:34:50 Martin Storsjö wrote: On Mon, 22 Apr 2024, Pali Rohár wrote: This patch series moves all aliases defined in crtdll.def.in, and msvcr*.def.in files into one common include file msvcrt-common.def.in. It reduces duplication of symbol alias definitions by defining symbols in more declarative manner. Moving aliases to one place uncovered that some def.in files were missing some alises (mostly for __ms_* printf/scanf symbols) or some were incorrectly defined (ctime for 64-bit msvcr90d.def.in was defined as alias to _ctime32 instead of _ctime64, or _findfirst for 64-bit msvcr120.def.in was defined as alias to symbol which does _not_ use 32-bit file length). For reference what this change affects, I'm attaching a difference which was generated for each CRT def.in file by command ($PLAT: DEF_I386 DEF_X64): cpp -x c -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed -E 's/\s*;.*//' | LC_ALL=C sort -u I presume you didn't diff the changes for ucrtbase.def.in? Because it seems to be changes that do affect the output from that one, in patch 10/10. Ou, I completely forgot to look at ucrtbase difference. Too many CRT libs. For reference here is the difference before and after 10/10 patch. I will inspect it and let know about issues. --- lib32/ucrtbase.def.in +++ lib32/ucrtbase.def.in -_findfirst == _findfirst64 +_findfirst == _findfirst32 -_findnext == _findnext64 +_findnext == _findnext32 +_findfirsti64 == _findfirst32i64 +_findnexti64 == _findnext32i64 +_fstat == _fstat32 +_fstati64 == _fstat32i64 -_ftime == _ftime64 +_ftime == _ftime32 -_futime == _futime64 +_futime == _futime32 +_mkgmtime == _mkgmtime32 +_stat == _stat32 +_stati64 == _stat32i64 -_utime == _utime64 +_utime == _utime32 +_wctime == _wctime32 +_wfindfirst == _wfindfirst32 +_wfindfirsti64 == _wfindfirst32i64 +_wfindnext == _wfindnext32 +_wfindnexti64 == _wfindnext32i64 +_wstat == _wstat32 +_wstati64 == _wstat32i64 -_wutime == _wutime64 +_wutime == _wutime32 -ctime == _ctime64 +ctime == _ctime32 +difftime == _difftime32 -gmtime == _gmtime64 +gmtime == _gmtime32 -localtime == _localtime64 +localtime == _localtime32 -mktime == _mktime64 +mktime == _mktime32 -time == _time64 +time == _time32 -utime == _utime64 --- lib64/ucrtbase.def.in +++ lib64/ucrtbase.def.in -_findfirst == _findfirst64 +_findfirst == _findfirst64i32 On 64-bit is mingw-w64's io.h using: #define _findfirst _findfirst64i32 And seem that this also matches 64-bit msvcrt.dll. So I think that current ucrtbase.def.in has wrongly defined _findfirst symbol (and also _findnext). And my change is fixing it. Yes, it's probably fixing it - but it should be in a different patch. And the change for lib32/ucrtbase.def.in, making it point at _findfirst32 is wrong IMO, it should also point at _findfirst64i32. // 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 10/10] crt: Move find, stat and time aliases to def-include/msvcrt-common.def.in
On Thu, 25 Apr 2024, Pali Rohár wrote: On Wednesday 24 April 2024 23:41:24 Martin Storsjö wrote: On Mon, 22 Apr 2024, Pali Rohár wrote: diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in b/mingw-w64-crt/lib-common/ucrtbase.def.in index 2d0552f277ef..c8fb1e33b1d7 100644 --- a/mingw-w64-crt/lib-common/ucrtbase.def.in +++ b/mingw-w64-crt/lib-common/ucrtbase.def.in @@ -327,12 +327,10 @@ _filelength _filelengthi64 _fileno _findclose -_findfirst == _findfirst64 Note how we unconditionally had these macros pointing at _findfirst64 in ucrt, regardless of architecture. I must admit that this is an interesting issue. I looked at the mingw-w64-headers/crt/io.h file now and it is not set unconditionally as you wrote. I didn't say that the headers unconditionally uses it this way. I just said that the exist, most probably buggy, def file line right above what I quoted, unconditionally does "_findfirst == _findfirst64" for all architectures. Yes it's probably wrong - but we shouldn't be changing it in a refactoring patch, that's all I tried to say here. Anyway, this def file defines symbol alias "_findfirst" for linking. And every c/c++ source file which includes headers files would result in object file which will use either "_findfirst32" or "_findfirst64i32". Not "_findfirst" symbol. So in my opinion, this change should be safe. It may very well be safe in practice, but I don't want such a subtle, unannounced change buried in a patch that refactors many hundreds of lines, where the rest mostly is a pure refactoring. I think that meaning of the symbols should be same independently of the used CRT library. And for me this looks like a bug that UCRT was resolving _findfirst to different ABI function than msvcrt, at link time. I disagree here. UCRT has a different ABI than msvcrt, overall, with time_t defaulting to 64 bit on UCRT on 32 bit platforms, contrary to msvcrt. I think the default symbol here should match what the headers default to, when used in a UCRT configuration. I guess that it was rare to hit this issue as it required to either not include mingw-w64 header files and declare functions manually. Or write application in other language which does not use mingw-w64 C header files (e.g. in assembly or something similar) but uses mingw-w64 CRT libraries for linking. Yes, this is not something that would be encountered often in practice, I agree with that. Please check what I wrote above. If you agree that this is a bug, I can prepare a separate fix for the UCRT (and then rebase 10/10 on top of it). I agree that the current state probably is a bug. As the headers default to 64 bit time_t, then _findfirst should probably resolve to _findfirst64i32, for both 32 and 64 bit. Similarly for the other symbols. That's most probably my original intent in how I set these up - that we point at the "64 bit version", but I missed that it really is _findfirst64i32 and not _findfirst64. I'd appreciate a patch that fixes these aliases, consistently for ucrtbase.def.in and the api-ms-win-crt-*.def.in, and then we can rebase patch 10/10 on top of it, where I'd expect no changes in the preprocessed output of the ucrt def files. Ou, and another files for which I forget api-ms-win-crt-*.def.in. And this is because they do not include that common .def.in file. I can look at them, but I would prefer to do it after all existing stuff is resolved as basically api-ms-win-crt-*.def.in does not use any common aliases. In my opinion, it would be better to change *crt*.def.in and api-ms-win-crt-*.def.in files to use common alias (would need refactor). Yes, that would indeed require a bit of refactoring. I'm not requesting you do it, but if you feel you want to take it on, feel free. Just make sure that the aliases in ucrtbase.def.in (or transitively from msvcrt-common.def.in) match api-ms-win-crt-*.def.in. // 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 00/10] crt: Move symbol aliases from CRT def files to msvcrt-common.def.in
On Thursday 25 April 2024 20:18:44 Pali Rohár wrote: > On Wednesday 24 April 2024 23:34:50 Martin Storsjö wrote: > > On Mon, 22 Apr 2024, Pali Rohár wrote: > > > > > This patch series moves all aliases defined in crtdll.def.in, and > > > msvcr*.def.in files into one common include file msvcrt-common.def.in. > > > > > > It reduces duplication of symbol alias definitions by defining symbols > > > in more declarative manner. > > > > > > Moving aliases to one place uncovered that some def.in files were > > > missing some alises (mostly for __ms_* printf/scanf symbols) or some > > > were incorrectly defined (ctime for 64-bit msvcr90d.def.in was defined > > > as alias to _ctime32 instead of _ctime64, or _findfirst for 64-bit > > > msvcr120.def.in was defined as alias to symbol which does _not_ use > > > 32-bit file length). > > > > > > For reference what this change affects, I'm attaching a difference which > > > was generated for each CRT def.in file by command ($PLAT: DEF_I386 > > > DEF_X64): > > > > > > cpp -x c -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed -E > > > 's/\s*;.*//' | LC_ALL=C sort -u > > > > I presume you didn't diff the changes for ucrtbase.def.in? Because it seems > > to be changes that do affect the output from that one, in patch 10/10. > > Ou, I completely forgot to look at ucrtbase difference. Too many CRT libs. > > For reference here is the difference before and after 10/10 patch. > I will inspect it and let know about issues. > > --- lib32/ucrtbase.def.in > +++ lib32/ucrtbase.def.in > -_findfirst == _findfirst64 > +_findfirst == _findfirst32 > -_findnext == _findnext64 > +_findnext == _findnext32 > +_findfirsti64 == _findfirst32i64 > +_findnexti64 == _findnext32i64 > +_fstat == _fstat32 > +_fstati64 == _fstat32i64 > -_ftime == _ftime64 > +_ftime == _ftime32 > -_futime == _futime64 > +_futime == _futime32 > +_mkgmtime == _mkgmtime32 > +_stat == _stat32 > +_stati64 == _stat32i64 > -_utime == _utime64 > +_utime == _utime32 > +_wctime == _wctime32 > +_wfindfirst == _wfindfirst32 > +_wfindfirsti64 == _wfindfirst32i64 > +_wfindnext == _wfindnext32 > +_wfindnexti64 == _wfindnext32i64 > +_wstat == _wstat32 > +_wstati64 == _wstat32i64 > -_wutime == _wutime64 > +_wutime == _wutime32 > -ctime == _ctime64 > +ctime == _ctime32 > +difftime == _difftime32 > -gmtime == _gmtime64 > +gmtime == _gmtime32 > -localtime == _localtime64 > +localtime == _localtime32 > -mktime == _mktime64 > +mktime == _mktime32 > -time == _time64 > +time == _time32 > -utime == _utime64 > > --- lib64/ucrtbase.def.in > +++ lib64/ucrtbase.def.in > -_findfirst == _findfirst64 > +_findfirst == _findfirst64i32 On 64-bit is mingw-w64's io.h using: #define _findfirst _findfirst64i32 And seem that this also matches 64-bit msvcrt.dll. So I think that current ucrtbase.def.in has wrongly defined _findfirst symbol (and also _findnext). And my change is fixing it. Please let me know what is your opinion. > -_findnext == _findnext64 > +_findnext == _findnext64i32 > +_findfirsti64 == _findfirst64 > +_findnexti64 == _findnext64 > +_fstat == _fstat64i32 > +_fstati64 == _fstat64 > +_mkgmtime == _mkgmtime64 > +_stat == _stat64i32 > +_stati64 == _stat64 > +_wctime == _wctime64 > +_wfindfirst == _wfindfirst64i32 > +_wfindfirsti64 == _wfindfirst64 > +_wfindnext == _wfindnext64i32 > +_wfindnexti64 == _wfindnext64 > +_wstat == _wstat64i32 > +_wstati64 == _wstat64 > +difftime == _difftime64 > -utime == _utime64 But this removal of the utime symbol alias without any replacement is a bug. I will need to fix patch 10 to properly define it (applies for lib32 and lib64 variants). ___ 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 00/10] crt: Move symbol aliases from CRT def files to msvcrt-common.def.in
On Thursday 25 April 2024 14:01:16 Martin Storsjö wrote: > On Wed, 24 Apr 2024, Martin Storsjö wrote: > > > On Mon, 22 Apr 2024, Pali Rohár wrote: > > > > > This patch series moves all aliases defined in crtdll.def.in, and > > > msvcr*.def.in files into one common include file msvcrt-common.def.in. > > > > > > It reduces duplication of symbol alias definitions by defining symbols > > > in more declarative manner. > > > > > > Moving aliases to one place uncovered that some def.in files were > > > missing some alises (mostly for __ms_* printf/scanf symbols) or some > > > were incorrectly defined (ctime for 64-bit msvcr90d.def.in was defined > > > as alias to _ctime32 instead of _ctime64, or _findfirst for 64-bit > > > msvcr120.def.in was defined as alias to symbol which does _not_ use > > > 32-bit file length). > > > > > > For reference what this change affects, I'm attaching a difference which > > > was generated for each CRT def.in file by command ($PLAT: DEF_I386 > > > DEF_X64): > > > > > > cpp -x c -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed > > > -E 's/\s*;.*//' | LC_ALL=C sort -u > > > > I presume you didn't diff the changes for ucrtbase.def.in? Because it > > seems to be changes that do affect the output from that one, in patch > > 10/10. > > > > I looked closely at patches 1-9, and they seemed fine, so if you can > > recheck that they don't affect the preprocessed output for ucrtbase as > > well, we could land them and look at polishing the last one a bit more. > > I checked that the output from preprocessing ucrtbase.def.in is unchanged by > patches 1-9, so I pushed them. The output after patch 10 does change though, > as expected, so I'll leave that one for now. > > // Martin Ok, thanks! I'm looking at patch 10. ___ 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 10/10] crt: Move find, stat and time aliases to def-include/msvcrt-common.def.in
On Wednesday 24 April 2024 23:41:24 Martin Storsjö wrote: > On Mon, 22 Apr 2024, Pali Rohár wrote: > > > Add 4 new macros FIXED_SIZE_SYMBOLS, NO_I64_FIXED_SIZE, > > NO_FIXED_SIZE_64_ALIAS and NO_TIME_ALIAS to distinguish > > between different crt versions. > > --- > > .../def-include/msvcrt-common.def.in | 154 ++ > > mingw-w64-crt/lib-common/msvcr120_app.def.in | 33 +--- > > mingw-w64-crt/lib-common/msvcrt.def.in| 23 +-- > > mingw-w64-crt/lib-common/ucrtbase.def.in | 12 -- > > mingw-w64-crt/lib32/crtdll.def.in | 12 +- > > mingw-w64-crt/lib32/msvcr100.def.in | 18 -- > > mingw-w64-crt/lib32/msvcr110.def.in | 18 -- > > mingw-w64-crt/lib32/msvcr120.def.in | 14 -- > > mingw-w64-crt/lib32/msvcr120d.def.in | 14 -- > > mingw-w64-crt/lib32/msvcr70.def.in| 12 +- > > mingw-w64-crt/lib32/msvcr71.def.in| 12 +- > > mingw-w64-crt/lib32/msvcr80.def.in| 22 --- > > mingw-w64-crt/lib32/msvcr90.def.in| 18 -- > > mingw-w64-crt/lib32/msvcr90d.def.in | 17 -- > > mingw-w64-crt/lib32/msvcrt10.def.in | 12 +- > > mingw-w64-crt/lib32/msvcrt20.def.in | 13 +- > > mingw-w64-crt/lib32/msvcrt40.def.in | 12 +- > > mingw-w64-crt/lib64/msvcr100.def.in | 18 -- > > mingw-w64-crt/lib64/msvcr110.def.in | 18 -- > > mingw-w64-crt/lib64/msvcr120.def.in | 14 -- > > mingw-w64-crt/lib64/msvcr120d.def.in | 13 -- > > mingw-w64-crt/lib64/msvcr80.def.in| 22 --- > > mingw-w64-crt/lib64/msvcr90.def.in| 18 -- > > mingw-w64-crt/lib64/msvcr90d.def.in | 18 -- > > 24 files changed, 169 insertions(+), 368 deletions(-) > > > > diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in > > b/mingw-w64-crt/def-include/msvcrt-common.def.in > > index 3e2c674d3699..abca29686531 100644 > > --- a/mingw-w64-crt/def-include/msvcrt-common.def.in > > +++ b/mingw-w64-crt/def-include/msvcrt-common.def.in > > @@ -197,6 +197,160 @@ _strtoimax_l == _strtoi64_l > > _strtoumax_l == _strtoui64_l > > #endif > > > > +; This is list of find symbol aliases, every CRT library has either find > > symbols with SIZE suffix or without them > > +#ifdef FIXED_SIZE_SYMBOLS > > +F32(_findfirst32 == _findfirst) > > +F64(_findfirst64i32 == _findfirst) > > +#ifndef NO_I64_FIXED_SIZE > > +F32(_findfirst32i64 == _findfirsti64) > > +#ifndef NO_FIXED_SIZE_64_ALIAS > > +F64(_findfirst64 == _findfirsti64) > > +#endif > > +#endif > > +F32(_findnext32 == _findnext) > > +F64(_findnext64i32 == _findnext) > > +#ifndef NO_I64_FIXED_SIZE > > +F32(_findnext32i64 == _findnexti64) > > +#ifndef NO_FIXED_SIZE_64_ALIAS > > +F64(_findnext64 == _findnexti64) > > +#endif > > +#endif > > +#ifndef NO_WIDE_FIXED_SIZE > > +F32(_wfindfirst32 == _wfindfirst) > > +F64(_wfindfirst64i32 == _wfindfirst) > > +#ifndef NO_I64_FIXED_SIZE > > +F32(_wfindfirst32i64 == _wfindfirsti64) > > +#ifndef NO_FIXED_SIZE_64_ALIAS > > +F64(_wfindfirst64 == _wfindfirsti64) > > +#endif > > +#endif > > +F32(_wfindnext32 == _wfindnext) > > +F64(_wfindnext64i32 == _wfindnext) > > +#ifndef NO_I64_FIXED_SIZE > > +F32(_wfindnext32i64 == _wfindnexti64) > > +#ifndef NO_FIXED_SIZE_64_ALIAS > > +F64(_wfindnext64 == _wfindnexti64) > > +#endif > > +#endif > > +#endif > > +#else > > +F32(_findfirst == _findfirst32) > > +F64(_findfirst == _findfirst64i32) > > This is the case that gets used by ucrtbase.def.in, right? Yes, it should be. > > diff --git a/mingw-w64-crt/lib-common/ucrtbase.def.in > > b/mingw-w64-crt/lib-common/ucrtbase.def.in > > index 2d0552f277ef..c8fb1e33b1d7 100644 > > --- a/mingw-w64-crt/lib-common/ucrtbase.def.in > > +++ b/mingw-w64-crt/lib-common/ucrtbase.def.in > > @@ -327,12 +327,10 @@ _filelength > > _filelengthi64 > > _fileno > > _findclose > > -_findfirst == _findfirst64 > > Note how we unconditionally had these macros pointing at _findfirst64 in > ucrt, regardless of architecture. I must admit that this is an interesting issue. I looked at the mingw-w64-headers/crt/io.h file now and it is not set unconditionally as you wrote. There is: #ifdef _USE_32BIT_TIME_T ... #define _findfirst _findfirst32 ... #else ... #define _findfirst _findfirst64i32 ... #endif /* _USE_32BIT_TIME_T */ And then in mingw-w64-headers/crt/_mingw.h.in is defined: #if defined (_WIN32) && !defined (_WIN64) && !defined (__MINGW_USE_VC2005_COMPAT) && !defined (_UCRT) #ifndef _USE_32BIT_TIME_T #define _USE_32BIT_TIME_T #endif #endif And then in mingw-w64-headers/crt/corecrt.h is defined: #ifdef _USE_32BIT_TIME_T #ifdef _WIN64 #error You cannot use 32-bit time_t (_USE_32BIT_TIME_T) with _WIN64 #undef _USE_32BIT_TIME_T #endif #endif /* _USE_32BIT_TIME_T */ So it means that 32-bit UCRT application can define _USE_32BIT_TIME_T before including header files and it will use 32-bit time_t. Anyway, this def file defines symbol alias "_findfirst" for linking. And every c/c++ source
Re: [Mingw-w64-public] [PATCH 00/10] crt: Move symbol aliases from CRT def files to msvcrt-common.def.in
On Wednesday 24 April 2024 23:34:50 Martin Storsjö wrote: > On Mon, 22 Apr 2024, Pali Rohár wrote: > > > This patch series moves all aliases defined in crtdll.def.in, and > > msvcr*.def.in files into one common include file msvcrt-common.def.in. > > > > It reduces duplication of symbol alias definitions by defining symbols > > in more declarative manner. > > > > Moving aliases to one place uncovered that some def.in files were > > missing some alises (mostly for __ms_* printf/scanf symbols) or some > > were incorrectly defined (ctime for 64-bit msvcr90d.def.in was defined > > as alias to _ctime32 instead of _ctime64, or _findfirst for 64-bit > > msvcr120.def.in was defined as alias to symbol which does _not_ use > > 32-bit file length). > > > > For reference what this change affects, I'm attaching a difference which > > was generated for each CRT def.in file by command ($PLAT: DEF_I386 DEF_X64): > > > > cpp -x c -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed -E > > 's/\s*;.*//' | LC_ALL=C sort -u > > I presume you didn't diff the changes for ucrtbase.def.in? Because it seems > to be changes that do affect the output from that one, in patch 10/10. Ou, I completely forgot to look at ucrtbase difference. Too many CRT libs. For reference here is the difference before and after 10/10 patch. I will inspect it and let know about issues. --- lib32/ucrtbase.def.in +++ lib32/ucrtbase.def.in -_findfirst == _findfirst64 +_findfirst == _findfirst32 -_findnext == _findnext64 +_findnext == _findnext32 +_findfirsti64 == _findfirst32i64 +_findnexti64 == _findnext32i64 +_fstat == _fstat32 +_fstati64 == _fstat32i64 -_ftime == _ftime64 +_ftime == _ftime32 -_futime == _futime64 +_futime == _futime32 +_mkgmtime == _mkgmtime32 +_stat == _stat32 +_stati64 == _stat32i64 -_utime == _utime64 +_utime == _utime32 +_wctime == _wctime32 +_wfindfirst == _wfindfirst32 +_wfindfirsti64 == _wfindfirst32i64 +_wfindnext == _wfindnext32 +_wfindnexti64 == _wfindnext32i64 +_wstat == _wstat32 +_wstati64 == _wstat32i64 -_wutime == _wutime64 +_wutime == _wutime32 -ctime == _ctime64 +ctime == _ctime32 +difftime == _difftime32 -gmtime == _gmtime64 +gmtime == _gmtime32 -localtime == _localtime64 +localtime == _localtime32 -mktime == _mktime64 +mktime == _mktime32 -time == _time64 +time == _time32 -utime == _utime64 --- lib64/ucrtbase.def.in +++ lib64/ucrtbase.def.in -_findfirst == _findfirst64 +_findfirst == _findfirst64i32 -_findnext == _findnext64 +_findnext == _findnext64i32 +_findfirsti64 == _findfirst64 +_findnexti64 == _findnext64 +_fstat == _fstat64i32 +_fstati64 == _fstat64 +_mkgmtime == _mkgmtime64 +_stat == _stat64i32 +_stati64 == _stat64 +_wctime == _wctime64 +_wfindfirst == _wfindfirst64i32 +_wfindfirsti64 == _wfindfirst64 +_wfindnext == _wfindnext64i32 +_wfindnexti64 == _wfindnext64 +_wstat == _wstat64i32 +_wstati64 == _wstat64 +difftime == _difftime64 -utime == _utime64 ___ 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: add a .gitignore
在 2024-04-25 20:36, Antonin Décimo 写道: Do you wish to create a separate repository for winpthreads, and commit .gitignore there? We're maintaining a separate repository at https://github.com/ocaml/winpthreads, with instructions on how to embed the subtree as a submodule in the ocaml sources at https://github.com/ocaml/ocaml/blob/trunk/HACKING.adoc#the-winpthreads-library-for-the-msvc-port. The subtree with these instructions allow us to keep the same commit id as the upstream in our winpthreads submodule. Fancy. Wow, haven't heard of `git subtree` at all! Thanks for the idea. Pushed to master now. May I ask: it doesn't seem that winpthreads, or other mingw-w64-libraries are tied to a specific commit of mingw. Maybe they don't need to be in the mingw-w64 "monorepo"? I understand it wouldn't be easy if they're used for instance to build mingw. This has been the case since SVN days. One advantage of SVN over Git is that it allows checking out subdirectories, so this was not an issue. Not sure about the precise reason though. -- Best regards, LIU Hao OpenPGP_signature.asc 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: add a .gitignore
> Do you wish to create a separate repository for winpthreads, and commit > .gitignore there? We're maintaining a separate repository at https://github.com/ocaml/winpthreads, with instructions on how to embed the subtree as a submodule in the ocaml sources at https://github.com/ocaml/ocaml/blob/trunk/HACKING.adoc#the-winpthreads-library-for-the-msvc-port. The subtree with these instructions allow us to keep the same commit id as the upstream in our winpthreads submodule. Fancy. > In mingw-w64 the top-level .gitignore applies and there is no need to > maintain the same one in a > subdirectory. If you would like to fork a separate directory, you can just > copy the top-level one. > (BTW I don't think it's necessary; you can fork mingw-w64 as a whole, and it > makes rebasing > automatic and easier.) To be clear, this patch is a copy of the top-level gitignore. May I ask: it doesn't seem that winpthreads, or other mingw-w64-libraries are tied to a specific commit of mingw. Maybe they don't need to be in the mingw-w64 "monorepo"? I understand it wouldn't be easy if they're used for instance to build mingw. Best regards, -- Antonin ___ 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 00/10] crt: Move symbol aliases from CRT def files to msvcrt-common.def.in
On Wed, 24 Apr 2024, Martin Storsjö wrote: On Mon, 22 Apr 2024, Pali Rohár wrote: This patch series moves all aliases defined in crtdll.def.in, and msvcr*.def.in files into one common include file msvcrt-common.def.in. It reduces duplication of symbol alias definitions by defining symbols in more declarative manner. Moving aliases to one place uncovered that some def.in files were missing some alises (mostly for __ms_* printf/scanf symbols) or some were incorrectly defined (ctime for 64-bit msvcr90d.def.in was defined as alias to _ctime32 instead of _ctime64, or _findfirst for 64-bit msvcr120.def.in was defined as alias to symbol which does _not_ use 32-bit file length). For reference what this change affects, I'm attaching a difference which was generated for each CRT def.in file by command ($PLAT: DEF_I386 DEF_X64): cpp -x c -Wp,-w -undef -P -Imingw-w64-crt/def-include -D$PLAT | sed -E 's/\s*;.*//' | LC_ALL=C sort -u I presume you didn't diff the changes for ucrtbase.def.in? Because it seems to be changes that do affect the output from that one, in patch 10/10. I looked closely at patches 1-9, and they seemed fine, so if you can recheck that they don't affect the preprocessed output for ucrtbase as well, we could land them and look at polishing the last one a bit more. I checked that the output from preprocessing ucrtbase.def.in is unchanged by patches 1-9, so I pushed them. The output after patch 10 does change though, as expected, so I'll leave that one for 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: Avoid using MemoryBarrier() in public headers with GCC/Clang
On Wed, 24 Apr 2024, LIU Hao wrote:
在 2024-04-24 20:11, Martin Storsjö 写道:
Agreed, although it's less of a regression if we require windows headers
for pthread_cleanup_push only when built with MSVC, than making it required
for everybody, as the library wasn't usable at all with MSVC until
recently.
However, I looked at the output of _ReadWriteBarrier(), and in most cases,
it seems like this doesn't seem like something equivalent to
__sync_synchronize. In the mingw headers, it's just defined as __asm__
__volatile__ ("" ::: "memory"), i.e. something that stops the compiler from
reordering code across this point, but does nothing for synchronizing with
other threads. See e.g. https://godbolt.org/z/ccGdd7P44.
I.e., for now, I still think this patch in the shape I posted it, is the
best candidate for unbreaking this case.
This reminds me that `MemoryBarrier()` is a full barrier (`atomic_seq_cst`)
instead of a load-store barrier (`atomic_acq_rel`)., and the barriers are
there to prevent partial writes in case of asynchronous cancellation.
The patch looks correct to me. Please go ahead and apply. Thanks.
Applied now, thanks!
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
