Should we migrate gcc from winpthreads to mcfgthread?

[lhmouse]

I am speaking for myself, not for the mingw-w64 project.

Recently, as usual however, there was a report about deadlocks in winpthreads ¹. While I believe people are sincere and professional, some of these are not reproducible, and are presumed to have been fixed by a fragile patch ².

The threading library is so fundamental that, although not being 100% necessary, I think it's time to start replacing winpthreads with something more modern, such as mcfgthread ³.

The pros of winpthreads are:

1. winpthreads supports Windows XP; mcfgthread only supports Vista.
2. winpthreads provides more complete POSIX APIs, such scheduler and RW locks; mcfgthread only provides those required by libgcc and libstdc++.

On the other hand, the pros of mcfgthread are

1. mcfgthread is generally more efficient, outperforming native SRWLOCKs; winpthreads' condition variable and thread-specific storage access is slow.
2. mcfgthread provides slim mutex and condvar, which take up storage as pointers, consume no additional resource, and require no cleanup.
3. mcfgthread provides __cxa_finalize() as per Itanium ABI.

Footnotes

1. https://sourceforge.net/p/mingw-w64/bugs/774/ ↩

2. https://github.com/mingw-w64/mingw-w64/commit/330025c54b85512d54b6960fad07498365c8fee3 ↩

3. https://github.com/lhmouse/mcfgthread ↩

[lazka]

2. winpthreads provides more complete POSIX APIs, such scheduler and RW locks; mcfgthread only provides those required by libgcc and libstdc++.

• Is this a design limitation, or "just" needs more work?

Other questions:

• Can/could winpthreads and mcfgthread coexist in MSYS2?
• Is it just a replacement for gcc/libstdc++, or should/could other things also migrate to it?

[lhmouse]

Oops, sorry, I mistook this repo for MINGW-packages. Please move it there.

MSYS2 itself uses Cygwin's pthread library I think? There should be no issue.

[lazka]

MSYS2 itself uses Cygwin's pthread library I think? There should be no issue.

I think this, yes: https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/thread.cc

[lhmouse]

2. winpthreads provides more complete POSIX APIs, such scheduler and RW locks; mcfgthread only provides those required by libgcc and libstdc++.

• Is this a design limitation, or "just" needs more work?

It's mostly the latter.

Scheduling APIs are fairly easy to implement, as they are just wrappers for Windows APIs, while clock and the semaphore APIs are a bit more complex. The POSIX semaphore can be named or unnamed, so probably we can have sem_t as a struct holding solely the handle to a Windows semaphore. At least, it's no magic.

Other questions:

• Can/could winpthreads and mcfgthread coexist in MSYS2?
• Is it just a replacement for gcc/libstdc++, or should/could other things also migrate to it?

In principle they can. Not sure whether it is a good idea, though, as some configure scripts attempt to check whether linking against pthread succeeds or not, and I am not sure whether they would interfere with each other. Anyway, code that calls pthread APIs explicitly, instead of referencing them via the C++ standard library, is unaffected.

Existent programs and libraries that use C++11 threads used to link against winpthreads, so they should continue to work. However, once rebuilt, they shouldn't depend on winpthreads any more.

[lazka]

ok, I see, I was initially thinking this is a winpthread alternative, but it is a gthread alternative, this my questions didn't make much sense :)

Some more questions:

• Do you see any problems with existing projects dynamically or statically linking libstdc++ and assuming pthreads being used?

• Would it makes sense to upstream the gthread implementation into gcc itself, so there is no extra library needed, similar to libc++? Or patch it in and build it together.

[lhmouse]

• Do you see any problems with existing projects dynamically or statically linking libstdc++ and assuming pthreads being used?

No. The only issue that I am aware of is that one may assume std::thread::native_handle() returns a pthread_t and passes it to other pthread functions; however I haven't seen anyone do this.

• Would it makes sense to upstream the gthread implementation into gcc itself, so there is no extra library needed, similar to libc++? Or patch it in and build it together.

While it may simplify distribution of such supplementary libraries, this library depends on no details about GCC - unlike libssp, libquadmath, etc.; even libstdc++ depends on some GCC builtin functions - and is not to be maintained by GCC developers. I am not denying the possibility though, I am a bit negative whether they will have any interest.

[revelator]

well from personal experience i can say mcfgthread works very well with gcc :) the only downside im aware of is that it wont work on anything older than Win vista so thats pretty moot.

[lhmouse]

well from personal experience i can say mcfgthread works very well with gcc :) the only downside im aware of is that it wont work on anything older than Win vista so thats pretty moot.

Thanks for the feedback.

MSYS2 has been Vista-only Vista-or-above-only for many years (and will be Windows 8 only Windows-8.1-or-above-only lately this year) so I think mcfgthread fits here.

[1480c1]

Might need to clarify Vista and above only rather than Vista-only, I got confused for a moment

[revelator]

thats why i ment the point was rather moot ;)

[revelator]

one strange problem turned up when trying to port gcc to mcfgthread the mcfgthread gcc bootstrap seems to do something odd to __cpuid erroring out because it only detects __cpuid as having 2 variables instead of the 5 needed in libstdc++ random.cc so i cannot build it as is. also theres a strange error with the latest crt complaining about TLS failure, this seems to be due to a recently added patch by martin storsjoe in the mingw-w64 abi.

[lhmouse]

one strange problem turned up when trying to port gcc to mcfgthread the mcfgthread gcc bootstrap seems to do something odd to __cpuid erroring out because it only detects __cpuid as having 2 variables instead of the 5 needed in libstdc++ random.cc so i cannot build it as is. also theres a strange error with the latest crt complaining about TLS failure, this seems to be due to a recently added patch by martin storsjoe in the mingw-w64 abi.

May I ask which GCC version you are trying to bootstrap? I have been building GCC 12 for a few months and have not seen issues around __cpuid so far. I will perform a new build today and see whether the problem persists.

mcfgthread can work with the vanilla mingw-w64 CRT or patched CRT (so exit() etc. work as specified by standards). Replacing the CRT requires a cross-compilation setup. I think I should have documented this; here are some brief instructions, but I can copy these elsewhere if that's desired:

1. Install vanilla toolchains: pacman -S mingw-w64-{i686,x86_64,ucrt-x86_64}-gcc-git
2. Apply patches for GCC and mingw-w64 CRT.
3. Build & install mingw-w64 headers.
4. Build & install mingw-w64-gcc with --enable-threads=mcf --disable-bootstrap.
   This creates a compiler that runs on the vanilla CRT, but targets the patched CRT.
5. Build & install mingw-w64 patched CRT.
6. Rebuild & install GCC with --enable-bootstrap.

[FrankHB]

It looks virtually OK if older versions of Windows are not supported. One more thing: native_handle is implementation-defined, so there should be sufficient documents for the change, whether it is upstreamed or not.

[lhmouse]

It looks virtually OK if older versions of Windows are not supported. One more thing: native_handle is implementation-defined, so there should be sufficient documents for the change, whether it is upstreamed or not.

The native_handle_type type is an alias for __gthread_t, which is an alias for struct __MCF_thread* defined in 'thread.h'. Specifically, native_handle() now returns a __MCF_thread*. One can't assume that it is a pthread_t or Windows HANDLE.

[lhmouse]

I have successfully bootstrapped GCC 12.2.1 (release branch) and observed no issue so far.

• Source: https://github.com/lhmouse/MINGW-packages/tree/master_2022-08-23
• Binary: https://gcc-mcf.lhmouse.com/

[xtemp09]

I'd like to have mcfgthreads upstream. There will be no change for end user, except for independance from winpthreads and increased speed on certain projects.

[lazka]

@lhmouse thanks for trying to upstream things.

https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602704.html

[lhmouse]

I have also prepared a patch for mingw-w64 just now: https://sourceforge.net/p/mingw-w64/mailman/message/37717940/

If these two series of patches can be merged I think we can have it after the next GCC release.

[lhmouse]

The mcf thread model has been merged into GCC trunk, and will be available since GCC 13.

Sadly I am not able to bootstrap GCC trunk at this moment: The stage1 libstdc++ fails to build due to undefined references to SJLJ exception routines, and (since 3 days ago) genautomata hangs. Patches for mcf thread model and mingw-w64 have been tested on GCC 12.

[mati865]

The mcf thread model has been merged into GCC trunk, and will be available since GCC 13.

Apparently many developers on gcc-patches mailing list have raised their concerns this is not the solution for threading problem. Since this is a breaking change for downstream users, IMO we should at the very least wait until there is overall agreement this is the right way.

[lhmouse]

I have received a number of negative expressions from others: https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/[email protected]/

Anyway, I am still maintaining my personal builds with those patches: https://github.com/lhmouse/MINGW-packages/tree/5f0010e6b9862ebd3343581de9febb46011fe39a/mingw-w64-crt-git

[carlkl]

Let me ask a different question: is the mcfgthread LGPL licence a potential problem here? mingw-w64 doesn't use LGPL'd code and for GCC there is the library exception clause. There are projects relying on mingw-w64 on Windows OS and the assumption that mingw-w64 doesn't contanimate their distributions with GPL and/or LGPL.

[lhmouse]

Headers are in the public domain [1]. Only source code (at the moment, only .c files) is licensed with LGPL. This allows combination of inline functions without a license, but generally, dynamic linking should be preferred.

[1] https://github.com/lhmouse/mcfgthread/blob/ad1df18fdbc0c1c6abc9b53420d0e7d0ad1c21bb/LICENSE.TXT#L1

[lhmouse]

GCC 13 bootstrapped and uploaded to https://gcc-mcf.lhmouse.com/.

The MCF thread model is part of GCC 13 and does not require a separate patch any longer.

[Tokrat]

I am currently trying to add McfgThread to my project, but it lack documentation, I have no idea how to do it. I am currently unzipping and replacing my file with the binary from https://gcc-mcf.lhmouse.com/ but it doesn't feel like the right way to do it.

I am writing here and not in a new issue because it feel like this is the only missing thing from this discussion.
Is there any news to have the library natively in gcc or msys2 ? what is the proper way to use the library ? (if I want my compiler to remplace the standard thread, not adding a custom thread to my program)

Also is it possible to link it statically ? even if there is the static file present, when I compile my program using the archive, at the end my .exe will not run unless I copy / past libmcfgthread-1.dll.

[lhmouse]

I am currently trying to add McfgThread to my project, but it lack documentation, I have no idea how to do it. I am currently unzipping and replacing my file with the binary from https://gcc-mcf.lhmouse.com/ but it doesn't feel like the right way to do it.

The recommended setup is to install mcfgthread and reconfigure & rebuild GCC with --enable-threads=mcf. The new thread model will be officially part of GCC 13; for older versions you would have to patch GCC source yourself. If other libraries use std::mutex, std::thread, etc. they all have to be rebuilt thereafter, e.g. boost.

I am writing here and not in a new issue because it feel like this is the only missing thing from this discussion. Is there any news to have the library natively in gcc or msys2 ? what is the proper way to use the library ? (if I want my compiler to remplace the standard thread, not adding a custom thread to my program)

As stated above you have to reconfigure & rebuild GCC with all its libraries. And don't forget to examine the output of gcc -v 2>&1 | fgrep 'Thread model:'.

Also is it possible to link it statically ? even if there is the static file present, when I compile my program using the archive, at the end my .exe will not run unless I copy / past libmcfgthread-1.dll.

Yes, you need -static. If you use my personal toolchain you can't just pass libmcfgthread.a to GCC and expect it to work, because -lmcfgthread exists in default libraries, and unless -static is given that would be shared.

FWIW, you could delete libmcfgthread.dll.a...

[Tokrat]

Ok I see, thanks for the help !
I am currently using your toolchain with GCC 13 and I have set -static in my program. It still asks me for libmcfgthread-1.dll but if i delete libmcfgthread-1.dll.a before compiling, it works, it seems weird. Do you have any idea why ?

[Tokrat]

ok i figure it out, i needed to set -static to the CMAKE_EXE_LINKER_FLAGS too, thanks it works :)

[xtemp09]

Windows 7 x64 user here. Whatever you do, please don't give up on us as easily as these Silicon Valley traitors.

So far I've found that mcfgthread supports Vista and newer.

[lhmouse]

The next release will drop Vista, due to introduction of QueryUnbiasedInterruptTime().

[revelator]

managed a full build of gcc-14.2.0 with mcfgthread, so far no problems observed.
quite a lot faster to :). i can make the builds avaliable to those who want to test them currently i have two forks of gcc-14.2.0 one standard and one intended for static runtime linking using code from TDM (heavily modified due to changes in the dwarf code).
both builds have 32 bit fortran ada grust objc which differs from yours since you removed most of those.

[carlkl]

One question: did you used PKGBUILD but with patches from tdm's gcc _PATCHES applied for your build?

[revelator]

i used a modified version of his patchset because some functions in dwarf changed but yeah with PKGBUILD.
my version also does not default to linking to the static runtimes unless told to so it can be used as normal as the shared runtimes dont use the TDM code. still it is a bit experimental so even if it builds most things weird crap might show up eventually so expect that it might not be stable yet.

the TDM code had a hook into the fde_split function in unwind_fde.c in previous versions but this function is gone so atm im experimenting to see where the best access point would be for hooking this part of the unwinder.

[revelator]

one snag gcc-14.2.0 is quite a lot stricter than previous versions so quite a lot of current packages cannot be built with it atm without adjusting some warning flags like -Wincompatible-pointer-types -Wint-conversion etc.

also after changing to mcfgthread im having problems building a few packages like tesseract-ocr which complains about undefined references to pthread types in libstdc++ ??? which is kinda odd.

[carlkl]

@revelator, I would be interested especially in gcc 32-bit with ucrt. Did you created a build in this configuration?

[revelator]

i can make a try though i havent had much success with in the past :).

[revelator]

looks like winlibs have a 32 bit ucrt based gcc toolchain here https://winlibs.com/

but i suspect you might want a TDM based one ?

[carlkl]

I know the winlibs toolchain. However I want to build my own based on the scripts and patches of this repo, maybe with the help of the winlibs toolchain as a start for bootstrapping. I'm curious which tdm patches are relevant for the 32-bit dwarf combination and the the static option.

[revelator]

0160-shared-pointers.patch
this one is, as standard it uses the shared gcc runtimes but if using say -static-libgcc it uses the TDM gcc unwinders, if using -static-libgcc -static-libstdc++ it uses the TDM unwinders and the TDM C++ exception code. this is not 100% foolproff as linking to plain -lstdc++ allways links in the shared libstdc++ dll as both libraries use the same namespace. so i use a shellscript to copy libstdc++.a to libstdc++.dll.a if i want to make sure.

the winlibs toolchain should be enough for bootstrapping a toolchain of your own :)

[revelator]

of the top of my head you need gmp mpfr isl mpc libiconv zlib and the zstd libraries as dependencies to build your own gcc toolchain.-then you build a version of the mingw-w64 abi -> with ucrt bindings (you can edit the PKGBUILD's with notepad++ and set it up for ucrt bindings for i686).
then build binutils against the ucrt compiler and you have the start of a 32 bit ucrt buildchain.

the patch from me you can yank into gcc's PKGBUILD script but first you should build a bootstrap compiler without it as that works best.
then when you have your toolchain setup as you want bootstrap gcc with the patch from me and you should be in business.

tbh i newer tested the TDM code with ucrt so i cannot say if it will work without problems so im curious to hear of your progress :)

[revelator]

for msvcrt the TDM patch looks good so far, no major issues detected yet.
the true test comes with the more complicated sources like ogre3d which i have yet to have success building with TDM (might also be a bug on they're side), besides some weirdness with gdk-pixbuf at some time everything built against the static runtimes have worked with the modified TDM code.

so at some point im going to make my own bootstrap of ucrt64 and ucrt32 with these modifications in place, but it might take a little before im sure there is no major breakage in the code.

[revelator]

ok there are a few problems pertaining to how msys2 mingw is set up atm.
rust cargo etc. cannot be built with mcfgthread. it seems to expect pthread and you get linker errors when trying to build it with mcf even if the winpthreads library is installed. i suspect this might be due to our llvm linking against pthread by default ?.

this unfortunatly breaks building a good deal of packages as even if i install rust from here it barfs on pthread even if i have both libraries installed. strangely this is one of the few packages that really dont like it.

[lhmouse]

ok there are a few problems pertaining to how msys2 mingw is set up atm.

rust cargo etc. cannot be built with mcfgthread. it seems to expect pthread and you get linker errors when trying to build it with mcf even if the winpthreads library is installed. i suspect this might be due to our llvm linking against pthread by default ?.

Maybe you can have a look at gcc -dumpspecs where default libraries are hard-coded.

[revelator]

ok it is LLVM, i just tried disabling pthreads in LLVM that stopped rust from complaining about pthread exports but instead it now cant find the mcfgthread exports so its broken with LLVM. Tbh i dont think mcf was ever added to it as an option but mstorsjø might shed some light on that. for pure gcc projects it works pretty well but that means we cannot build a rather huge part of the packages here with it since many of them rely on rust being avaliable.

[revelator]

hmm this but since it is build against mcf im not sure where else to look ->

*libgcc:
%{mthreads:-lmingwthrd} -lmingw32      %{static|static-libgcc:-lgcc -lgcc_eh}  %{!static:    %{!static-libgcc:      %{!shared:        %{!shared-libgcc:-lgcc -lgcc_eh}        %{shared-libgcc:-lgcc_s -lgcc}       }      %{shared:-lgcc_s -lgcc}     }   }     -lmingwex %{!mcrtdll=*:-lmsvcrt} %{mcrtdll=*:-l%*}    -lkernel32  -lmcfgthread -lkernel32 -lntdll

and maybe this ->

*lib:
%{pg:-lgmon} %{pthread:-lpthread} %{!no-pthread: } %{mwindows:-lgdi32 -lcomdlg32} %{fvtable-verify=preinit:-lvtv -lpsapi;         fvtable-verify=std:-lvtv -lpsapi} -ladvapi32 -lshell32 -luser32 -lkernel32 -lntdll

[mati865]

honestly I suggest you ask Rust team whether they are willing to support mcfgthread officially.

The bar for adding tier 3 targets is pretty low. All it'd take is a volunteer who would implement and maintain it.

[revelator]

well guess we would need a maintainer for keeping them up to speed with current versions then, but ouch :(

[Kreijstal]

will you mantain this llvm fork

[revelator]

sorry i would like to but im semi retired from development (health problems) so i only help with minor problems as far as my health allows. maintaining this would be a major strain on me. i would not mind collaborating though.

[revelator]

as for how it goes after patching everything to be compatible with mcf. i built about 70% of the packages here though i did have to disable a god awfull lot of warnings because with gcc-14.2.0 they are now errors.

so far many packages need to disable these to even build -> -Wint-conversion -Wincompatible-pointer-types -Wimplicit-function-types.
and a few of the more obscure ones.