win32 threading model

[palves]

I saw the GCC that comes with xpack uses the posix threading model. In GCC 13, the GCC win32 threading model implementation was rewritten, and it can now support C++11 std::thread and friends.

See gcc commit 9149a5b7e0a66b7b94d5b7db3194a975d18dea2f, which says:

    Reimplement GNU threads library on native Windows
    
    This reimplements the GNU threads library on native Windows (except for the
    Objective-C specific subset) using direct Win32 API calls, in lieu of the
    implementation based on semaphores.  This base implementations requires
    Windows XP/Server 2003, which was the default minimal setting of MinGW-W64
    until end of 2020.  This also adds the support required for the C++11 threads,
    using again direct Win32 API calls; this additional layer requires Windows
    Vista/Server 2008 and is enabled only if _WIN32_WINNT >= 0x0600.
    (...)

Are there plans on providing pre-built xpack gcc with the win32 threading model?

[ilg-ul]

If functional, sure, I can consider it for the next release, 13.3, due soon.

[ilg-ul]

I took a look at the commit and it seems to cover green threads, which are limited compared to posix threads.

Are you sure we want this?

[palves]

What do you mean by "green threads"? That term normally refers to threads scheduled by a userspace library, as opposed to threads scheduled by the kernel. But this commit is about kernel threads. It's about reimplementing the win32 model (which maps c11 & c++11 std::thread to win32 threads directly, without requiring the extra winpthreads dependency, and more efficiently), in a better way.

Are you perhaps confused by "gthread" ? That "g" stands for "gnu" or "gcc", not "green".

[ilg-ul]

I confess that I'm a bit confused, and I don't know exactly how to read your suggestion.

In the configuration there are several options to configure threads; in GCC there are --enable-threads and --enable-libstdcxx-threads, but in mingw-w64 there is also a separate libwinpthread, that implements pthreads on Windows.

For cross-platform consistency reasons, up to now I used --enable-threads=posix. The second option enables the use of threads in C++ and has no values, I guess it means posix too, via libwinpthread. Anyway, std::thread seems functional, I have several tests using them.

I did a new build with --enable-threads not specifying any value, and, if I read the results right, it selected the value win32, and there are no more references to -lpthread. The tests also passed, so I guess it is ok.

I'm tempted to update the scripts to use the explicit --enable-threads=win32, to have a reproducible configuration.

If you have a better understanding of these issues, please help me with a more detailed suggestion on how to reconfigure the build.

[palves]

The second option enables the use of threads in C++ and has no values, I guess it means posix too, via libwinpthread.

--enable-libstdcxx-threads has no argument because libstdc++ uses the gthreads abstraction provided by libgcc.

--enable-threads=win32|posix selects how that abstraction is implemented in libgcc.

"--enable-libstdcxx-threads --enable-threads=win32" should result in emiting C++ std::thread code that does not link with libwinpthread.

I'm tempted to update the scripts to use the explicit --enable-threads=win32, to have a reproducible configuration.

Other projects provide two different gcc builds, one for win32, another for posix. That might be more prudent. E.g., Ubuntu has both:

$ x86_64-w64-mingw32-gcc-posix -v
...
Thread model: posix
...
$ x86_64-w64-mingw32-gcc-win32 -v
...
Thread model: win32
...

Others at https://www.mingw-w64.org/downloads/ seem to do something like that too. E.g., https://winlibs.com/ provides posix and mfc model toolchains. Unfortunately, the win32 model reimplementation wasn't advertized at https://gcc.gnu.org/gcc-13/changes.html and many seem to have missed it.

BTW, I came here because I was searching the web for binary builds of mingw gcc 13 or newer that used the win32 model so that I wouldn't have to build it myself, and what attracted me to this project was fact that you provide both linux and windows binaries, with no need for an installation step on either. I had not heard of xPack before.

[ilg-ul]

"--enable-libstdcxx-threads --enable-threads=win32" should result in emiting C++ std::thread code that does not link with libwinpthread.

ok

Other projects provide two different gcc builds, one for win32, another for posix. That might be more prudent.

Yeah, but with a larger archive and more build time... :-(

Do you know of any disadvantages of configuring the toolchain with the win32 variant? I distribute libwinpthread anyways, so those who prefer POSIX threads I guess they can use them directly, isn't it?

you provide both linux and windows binaries

... and macOS.

binary builds of mingw gcc 13 ...

Please note that there are two packages, mingw-w64-gcc-xpack and gcc-xpack, apparently with the same functionality when regarded from Windows, but actually different when regarded from a cross-platform perspective.

gcc-xpack provides an executable named gcc that works the same on all supported platforms, i.e. it compiles natively.

mingw-w64-gcc-xpack provides a pair of executables (x86_64-w64-mingw32-gcc & i686-w64-mingw32-gcc) that generate windows 64/32-bit binaries, regardless the platform they run on, even on Linux or macOS.

The main use case for gcc-xpack is to compile native unit tests, with all tests looking the same and invoking gcc; mingw-w64-gcc-xpack is used to cross compile Windows binaries, for example some parts of QEMU or WineHQ.

However, on Windows, they are more or less equivalent.

[palves]

Do you know of any disadvantages of configuring the toolchain with the win32 variant?

I don't know of a disadvantage. I was just thinking of the potential binary compatibility break (mixing dlls built with posix and win32 models). No idea whether that is important to you or your users.

I distribute libwinpthread anyways, so those who prefer POSIX threads I guess they can use them directly, isn't it?

Yeah, good point.

BTW, I opened this bug with gcc, about them not documenting this change anywhere AFAICT: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115105

[ilg-ul]

So far, so good, no issues with switching to win32 threads.

I published some pre-release binaries:

• https://github.com/xpack-dev-tools/pre-releases/releases/tag/experimental

Please give them a try and let me know if they are functional for your projects too.

As with any toolchain installed in a custom location, you should either use -static-libstdc++ -static-libgcc, or handle the paths to the libraries (for example via -rpath on Linux).

[palves]

Nice. And GCC 14, perfect!

Please give them a try and let me know if they are functional for your projects too.

My projects are just gdb. :-) I tried xpack-mingw-w64-gcc-14.1.0-1-linux-x64.tar.gz to cross build mingw gdb from linux, and it worked nicely. I copied over the resulting gdb to windows and gave it a smoke test, and it starts and worked fine.

I am not currently setup to try the native windows build, but that is also a build I will most probably end up using too.

Thank you very much for this!

[palves]

Hi! Just to let you know that I've now managed to build native Windows GDB using the native Windows toolchain (xpack-mingw-w64-gcc-14.1.0-1-win32-x64.zip from the pre-release dir), successfully.

[ilg-ul]

Great!

It'll take me a few more days to make the final GCC 14.1 release, I'm currently working on the clang releases.