Fix build issues with mingw toolchain

  With a x86_64-pc-mingw32 toolchain there is a build issue
whether or not the --disable-threading option is used.
The problem happens because _WIN32_WINNT is defined to 0x501
before #include <mutex> which makes the compilation abort
due to missing support for __gthread_cond_t in std_mutex.h,
which is conditional on _WIN32_WINNT >= 0x600.

Fix the case when --disable-threading is used, by only
including <mutex> in gdb/complaints.c when STD_CXX_THREAD
is defined.

Additionally make the configure script try to #include <mutex>
to automatically select --disable-threading when the header file
is not able to compile.
---
 gdb/complaints.c     | 2 ++
 gdb/configure        | 1 +
 gdbserver/configure  | 1 +
 gdbsupport/common.m4 | 1 +
 gdbsupport/configure | 1 +
 5 files changed, 6 insertions(+)
  

>>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes:

Bernd> With a x86_64-pc-mingw32 toolchain there is a build issue
Bernd> whether or not the --disable-threading option is used.
Bernd> The problem happens because _WIN32_WINNT is defined to 0x501
Bernd> before #include <mutex> which makes the compilation abort
Bernd> due to missing support for __gthread_cond_t in std_mutex.h,
Bernd> which is conditional on _WIN32_WINNT >= 0x600.

Bernd> Fix the case when --disable-threading is used, by only
Bernd> including <mutex> in gdb/complaints.c when STD_CXX_THREAD
Bernd> is defined.

Bernd> Additionally make the configure script try to #include <mutex>
Bernd> to automatically select --disable-threading when the header file
Bernd> is not able to compile.

This looks reasonable to me.  Thank you.
Approved-By: Tom Tromey <tom@tromey.com>

I wonder if we could change _WIN32_WINNT when threading is enabled, so
the new gcc support could be used.

Tom
  

On 5/6/24 16:57, Tom Tromey wrote:
>>>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> 
> Bernd> With a x86_64-pc-mingw32 toolchain there is a build issue
> Bernd> whether or not the --disable-threading option is used.
> Bernd> The problem happens because _WIN32_WINNT is defined to 0x501
> Bernd> before #include <mutex> which makes the compilation abort
> Bernd> due to missing support for __gthread_cond_t in std_mutex.h,
> Bernd> which is conditional on _WIN32_WINNT >= 0x600.
> 
> Bernd> Fix the case when --disable-threading is used, by only
> Bernd> including <mutex> in gdb/complaints.c when STD_CXX_THREAD
> Bernd> is defined.
> 
> Bernd> Additionally make the configure script try to #include <mutex>
> Bernd> to automatically select --disable-threading when the header file
> Bernd> is not able to compile.
> 
> This looks reasonable to me.  Thank you.
> Approved-By: Tom Tromey <tom@tromey.com>
> 

Okay, pushed.

> I wonder if we could change _WIN32_WINNT when threading is enabled, so
> the new gcc support could be used.
> 

frankly I don't understand at all why the _WIN32_WINNT is set to this
specific value, and maybe that was a good idea when windows XP was the
latest version.  My feeling would be to remove that define all together.

The code looks like its intention is to raise the _WIN32_WINNT from
4.x to 5.01, but instead it lowers the _WIN32_WINNT version
from 10.0 to 5.01 at least with my toolchain, where this define is not
a pre-defined value, but something that is set to 0x0a00 by <_minghw.h>,
but only if it is not fixed to something else.

However I am not an expert in this area, and I have only tried this with
my self-built cross-toolchain.  What I can tell, is that although I have
no working <pthread.h> in my sysroot, the std::thread implementation seems
to work, as long as _WIN32_WINNT is set to something >= 0x0600.


Thanks
Bernd


> Tom
  

>>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes:

>> I wonder if we could change _WIN32_WINNT when threading is enabled, so
>> the new gcc support could be used.

Bernd> frankly I don't understand at all why the _WIN32_WINNT is set to this
Bernd> specific value, and maybe that was a good idea when windows XP was the
Bernd> latest version.  My feeling would be to remove that define all together.

The addition itself seems to be commit 353ea2d1, which has some
explanation.  I gather the idea is that, this way, a gdb built on
Windows will work all the way back to NT.

I tried changing the value but Eli objected:

https://sourceware.org/pipermail/gdb-patches/2021-October/182443.html

Internally at AdaCore we still have this part of the change installed,
precisely to pick up the mingw threading support from gcc; plus we have
no need for Windows XP.

From https://en.wikipedia.org/wiki/Windows_XP#Support_lifecycle, I
gather that XP is still in reasonably wide use.  I'm not sure how many
developers use it, though, or even if gdb actually does run there, not
having access to such a machine myself.

I'm sympathetic to changing this somehow but I don't know how to make
progress on it.

Tom
  

Am Montag, 6. Mai 2024 um 22:18:50 MESZ hat Tom Tromey <tromey@adacore.com> Folgendes geschrieben:

> >>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
>
> >> I wonder if we could change _WIN32_WINNT when threading is enabled, so
> >> the new gcc support could be used.
>
> Bernd> frankly I don't understand at all why the _WIN32_WINNT is set to this
> Bernd> specific value, and maybe that was a good idea when windows XP was the
> Bernd> latest version.  My feeling would be to remove that define all together.
>
> The addition itself seems to be commit 353ea2d1, which has some
> explanation.  I gather the idea is that, this way, a gdb built on
> Windows will work all the way back to NT.
>
> I tried changing the value but Eli objected:
>
> https://sourceware.org/pipermail/gdb-patches/2021-October/182443.html
>
> Internally at AdaCore we still have this part of the change installed,
> precisely to pick up the mingw threading support from gcc; plus we have
> no need for Windows XP.
>
> From https://en.wikipedia.org/wiki/Windows_XP#Support_lifecycle, I
> gather that XP is still in reasonably wide use.  I'm not sure how many
> developers use it, though, or even if gdb actually does run there, not
> having access to such a machine myself.
>
> I'm sympathetic to changing this somehow but I don't know how to make
> progress on it.

Coincidentally I installed XP on a VM last week, because I was also curious
if my gdb-14.2 build works there, and it does.

If you don't need XP support, can't you just define _WIN32_WINNT in CPPFLAGS?


Hannes
  

>>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes:

Hannes> If you don't need XP support, can't you just define _WIN32_WINNT
Hannes> in CPPFLAGS?

Yeah, it seems possible.  Maybe the problem is that unless you remember
this (it seems pretty obscure), a mingw build with a newer version of
GCC is going to fail due to libstdc++ wanting an older version that
gdb's default.

Tom
  

> From: Tom Tromey <tromey@adacore.com>
> Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,  Tom Tromey
>  <tromey@adacore.com>,  "gdb-patches@sourceware.org"
>  <gdb-patches@sourceware.org>
> Date: Fri, 10 May 2024 11:24:18 -0600
> 
> >>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes:
> 
> Hannes> If you don't need XP support, can't you just define _WIN32_WINNT
> Hannes> in CPPFLAGS?
> 
> Yeah, it seems possible.

It's possible, but it doesn't solve the problem, IME.  _WIN32_WINNT is
a compile-time measure, intended to make sure that if you target your
program to versions of Windows >= N, running the program on older
versions will likely emit an error popup, and Windows will refuse to
run the program.  This is not what we want here: we do want to support
versions of Windows older than 10.

> Maybe the problem is that unless you remember
> this (it seems pretty obscure), a mingw build with a newer version of
> GCC is going to fail due to libstdc++ wanting an older version that
> gdb's default.

That is another problem with setting _WIN32_WINNT too high, yes.
  

> Date: Mon, 6 May 2024 19:09:37 +0200
> Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
> 
> On 5/6/24 16:57, Tom Tromey wrote:
> >>>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> > 
> > Bernd> With a x86_64-pc-mingw32 toolchain there is a build issue
> > Bernd> whether or not the --disable-threading option is used.
> > Bernd> The problem happens because _WIN32_WINNT is defined to 0x501
> > Bernd> before #include <mutex> which makes the compilation abort
> > Bernd> due to missing support for __gthread_cond_t in std_mutex.h,
> > Bernd> which is conditional on _WIN32_WINNT >= 0x600.
> > 
> > Bernd> Fix the case when --disable-threading is used, by only
> > Bernd> including <mutex> in gdb/complaints.c when STD_CXX_THREAD
> > Bernd> is defined.
> > 
> > Bernd> Additionally make the configure script try to #include <mutex>
> > Bernd> to automatically select --disable-threading when the header file
> > Bernd> is not able to compile.
> > 
> > This looks reasonable to me.  Thank you.
> > Approved-By: Tom Tromey <tom@tromey.com>
> > 
> 
> Okay, pushed.
> 
> > I wonder if we could change _WIN32_WINNT when threading is enabled, so
> > the new gcc support could be used.
> > 
> 
> frankly I don't understand at all why the _WIN32_WINNT is set to this
> specific value, and maybe that was a good idea when windows XP was the
> latest version.  My feeling would be to remove that define all together.
> 
> The code looks like its intention is to raise the _WIN32_WINNT from
> 4.x to 5.01, but instead it lowers the _WIN32_WINNT version
> from 10.0 to 5.01 at least with my toolchain, where this define is not
> a pre-defined value, but something that is set to 0x0a00 by <_minghw.h>,
> but only if it is not fixed to something else.

That was not the intent, and if that setting lowers the value of
_WIN32_WINNT, we should IMO investigate why and fix that.

> However I am not an expert in this area, and I have only tried this with
> my self-built cross-toolchain.  What I can tell, is that although I have
> no working <pthread.h> in my sysroot, the std::thread implementation seems
> to work, as long as _WIN32_WINNT is set to something >= 0x0600.

If your MinGW headers have _WIN32_WINNT set to a value higher than
0x0501, that setting should have left it alone.  Please try to figure
out why that doesn't happen in your case, perhaps MinGW64 have changed
their defaults or something.
  

> From: Tom Tromey <tromey@adacore.com>
> Cc: Tom Tromey <tromey@adacore.com>,  "gdb-patches@sourceware.org"
>  <gdb-patches@sourceware.org>
> Date: Mon, 06 May 2024 14:18:16 -0600
> 
> >>>>> "Bernd" == Bernd Edlinger <bernd.edlinger@hotmail.de> writes:
> 
> >> I wonder if we could change _WIN32_WINNT when threading is enabled, so
> >> the new gcc support could be used.
> 
> Bernd> frankly I don't understand at all why the _WIN32_WINNT is set to this
> Bernd> specific value, and maybe that was a good idea when windows XP was the
> Bernd> latest version.  My feeling would be to remove that define all together.
> 
> The addition itself seems to be commit 353ea2d1, which has some
> explanation.  I gather the idea is that, this way, a gdb built on
> Windows will work all the way back to NT.
> 
> I tried changing the value but Eli objected:
> 
> https://sourceware.org/pipermail/gdb-patches/2021-October/182443.html
> 
> Internally at AdaCore we still have this part of the change installed,
> precisely to pick up the mingw threading support from gcc; plus we have
> no need for Windows XP.
> 
> >From https://en.wikipedia.org/wiki/Windows_XP#Support_lifecycle, I
> gather that XP is still in reasonably wide use.  I'm not sure how many
> developers use it, though, or even if gdb actually does run there, not
> having access to such a machine myself.
> 
> I'm sympathetic to changing this somehow but I don't know how to make
> progress on it.

Once again, that change was not supposed to lower the value of
_WIN32_WINNT, only to raise it if by default it is lower than 0x0501.
If that's not what happens nowadays, I think we need to understand
why, and fix it so it doesn't lower the value.
  

> From: Tom Tromey <tromey@adacore.com>
> Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,  Tom Tromey
>  <tromey@adacore.com>,  "gdb-patches@sourceware.org"
>  <gdb-patches@sourceware.org>
> Date: Fri, 10 May 2024 11:24:18 -0600
> X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED,
>  DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,
>  SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6
> 
> >>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes:
> 
> Hannes> If you don't need XP support, can't you just define _WIN32_WINNT
> Hannes> in CPPFLAGS?
> 
> Yeah, it seems possible.  Maybe the problem is that unless you remember
> this (it seems pretty obscure), a mingw build with a newer version of
> GCC is going to fail due to libstdc++ wanting an older version that
> gdb's default.

That wasn't supposed to happen, if the system headers define
_WIN32_WINNT to a higher value than 0x0501.  Something is wrong, and
we should figure out what and why.
  

On 2024-05-10 18:24, Tom Tromey wrote:
>>>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes:
> 
> Hannes> If you don't need XP support, can't you just define _WIN32_WINNT
> Hannes> in CPPFLAGS?
> 
> Yeah, it seems possible.  Maybe the problem is that unless you remember
> this (it seems pretty obscure), a mingw build with a newer version of
> GCC is going to fail due to libstdc++ wanting an older version that
> gdb's default.

Presumably, if you pass --enable-threading=yes, but then configure detects 
threading can't work, the configure fails.  We could at least make the
error mention that you need to set _WIN32_WINNT to at least 0x600 in CFLAGS.

FWIW, I looked at this a while ago, and saw that Cygwin's oldest supported version
is Windows 8.1 (says so at https://www.cygwin.com/).

Many people using Windows gdb will use a Cygwin environment, or Msys2 (which is
a Cygwin fork), or "git bash" (which is an Msys2 fork...), and those won't work
on older Windows.  It's quite likely that number of people really really using
current GDB (for anything productive) on older Windows versions is very reduced,
if not approaching zero.
  

Hi Eli,

On 5/10/24 19:37, Eli Zaretskii wrote:
>> Date: Mon, 6 May 2024 19:09:37 +0200
>> Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
>> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
>>
>> On 5/6/24 16:57, Tom Tromey wrote:
>>> I wonder if we could change _WIN32_WINNT when threading is enabled, so
>>> the new gcc support could be used.
>>>
>>
>> frankly I don't understand at all why the _WIN32_WINNT is set to this
>> specific value, and maybe that was a good idea when windows XP was the
>> latest version.  My feeling would be to remove that define all together.
>>
>> The code looks like its intention is to raise the _WIN32_WINNT from
>> 4.x to 5.01, but instead it lowers the _WIN32_WINNT version
>> from 10.0 to 5.01 at least with my toolchain, where this define is not
>> a pre-defined value, but something that is set to 0x0a00 by <_minghw.h>,
>> but only if it is not fixed to something else.
> 
> That was not the intent, and if that setting lowers the value of
> _WIN32_WINNT, we should IMO investigate why and fix that.
> 

Hmm, what happens here is that _WIN32_WINNT is not a pre-defined symbol,
but __MINGW32__ is pre-defined.  So _WIN32_WINNT is not defined unless
<windows.h> is included first, but when "gdbsupport/common-defs.h"
is included, the _WIN32_WINNT is not yet defined, and therefore it is
set to 0x0501, now, later when <windows.h> is included, it includes
<_mingw.h>, but since the _WIN32_WINNT is already defined to 0x0501
that is kept this way.  And now, the <mutex> header file wont compile,
because the gthread.h is missing support for something similar to a
pthread condition variable.

I tried to include <windows.h> before overriding the _WIN32_WINNT define,
but that caused issues with something like <winsock2.h> if I remember
correctly.  I did not try to include <_mingw.h> because I expected
that to cause even more unexpected issues, e.g. with cygwin.

>> However I am not an expert in this area, and I have only tried this with
>> my self-built cross-toolchain.  What I can tell, is that although I have
>> no working <pthread.h> in my sysroot, the std::thread implementation seems
>> to work, as long as _WIN32_WINNT is set to something >= 0x0600.
> 
> If your MinGW headers have _WIN32_WINNT set to a value higher than
> 0x0501, that setting should have left it alone.  Please try to figure
> out why that doesn't happen in your case, perhaps MinGW64 have changed
> their defaults or something.

BTW: I tried the resulting executable with a Windows 10 VM, and it worked,
but:

$ x86_64-pc-mingw32-objdump -x gdb.exe | grep DLL
 vma:            Hint    Time      Forward  DLL       First
	DLL Name: bcrypt.dll
	DLL Name: KERNEL32.dll
	DLL Name: api-ms-win-crt-conio-l1-1-0.dll
	DLL Name: api-ms-win-crt-convert-l1-1-0.dll
	DLL Name: api-ms-win-crt-environment-l1-1-0.dll
	DLL Name: api-ms-win-crt-filesystem-l1-1-0.dll
	DLL Name: api-ms-win-crt-heap-l1-1-0.dll
	DLL Name: api-ms-win-crt-locale-l1-1-0.dll
	DLL Name: api-ms-win-crt-math-l1-1-0.dll
	DLL Name: api-ms-win-crt-private-l1-1-0.dll
	DLL Name: api-ms-win-crt-runtime-l1-1-0.dll
	DLL Name: api-ms-win-crt-stdio-l1-1-0.dll
	DLL Name: api-ms-win-crt-string-l1-1-0.dll
	DLL Name: api-ms-win-crt-time-l1-1-0.dll
	DLL Name: api-ms-win-crt-utility-l1-1-0.dll
	DLL Name: USER32.dll
	DLL Name: WS2_32.dll

So I am not an expert in this area, and I have not tried to run this on a
native XP machine, but somehow I wonder if defining _WIN32_WINNT to 0x501
does still do the trick that makes it execute on Windows XP ?

What do you think?


Thanks
Bernd.
  

> Date: Fri, 10 May 2024 21:36:42 +0200
> Cc: tom@tromey.com, gdb-patches@sourceware.org
> From: Bernd Edlinger <bernd.edlinger@hotmail.de>
> 
> >> frankly I don't understand at all why the _WIN32_WINNT is set to this
> >> specific value, and maybe that was a good idea when windows XP was the
> >> latest version.  My feeling would be to remove that define all together.
> >>
> >> The code looks like its intention is to raise the _WIN32_WINNT from
> >> 4.x to 5.01, but instead it lowers the _WIN32_WINNT version
> >> from 10.0 to 5.01 at least with my toolchain, where this define is not
> >> a pre-defined value, but something that is set to 0x0a00 by <_minghw.h>,
> >> but only if it is not fixed to something else.
> > 
> > That was not the intent, and if that setting lowers the value of
> > _WIN32_WINNT, we should IMO investigate why and fix that.
> 
> Hmm, what happens here is that _WIN32_WINNT is not a pre-defined symbol,
> but __MINGW32__ is pre-defined.  So _WIN32_WINNT is not defined unless
> <windows.h> is included first, but when "gdbsupport/common-defs.h"
> is included, the _WIN32_WINNT is not yet defined, and therefore it is
> set to 0x0501, now, later when <windows.h> is included, it includes
> <_mingw.h>, but since the _WIN32_WINNT is already defined to 0x0501
> that is kept this way.  And now, the <mutex> header file wont compile,
> because the gthread.h is missing support for something similar to a
> pthread condition variable.

Thanks, I think I understand what happens, see below.

> I tried to include <windows.h> before overriding the _WIN32_WINNT define,
> but that caused issues with something like <winsock2.h> if I remember
> correctly.  I did not try to include <_mingw.h> because I expected
> that to cause even more unexpected issues, e.g. with cygwin.

No, _mingw.h is not supposed to define the default value of
_WIN32_WINNT.  It used to be w32api.h, and in mingw.org's MinGW that
still happens.  But MinGW64 deviated from that, so we need to adapt.

According to the Microsoft documentation, the default value of
_WIN32_WINNT is defined in sdkddkver.h, see

  https://learn.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=msvc-170

So what we need is to have

  #include <sdkddkver.h>

before the first test of _WIN32_WINNT, and then it should work in both
flavors on MinGW.  I verified that this header defines _WIN32_WINNT in
both flavors of MinGW.

Alternatively, we could unconditionally define _WIN32_WINNT to 0x0600,
if that is needed for threading support.  AFAIU, it should not
interfere with what common-defs.h is trying to do now, since the
problem that fragment tries to solve is to make sure _WIN32_WINNT is
not defined to anything _lower_ than 0x0501.  I think this alternative
is cleaner, since sdkddkver.h is included from windows.h and defines
additional version-related constants based on _WIN32_WINNT (which
other Windows headers perhaps need).  If you decide to use this latter
alternative, please add there a comment saying that we still support
XP, but 0x0600 is required for threading when it is supported on
Windows.

> BTW: I tried the resulting executable with a Windows 10 VM, and it worked,
> but:
> 
> $ x86_64-pc-mingw32-objdump -x gdb.exe | grep DLL
>  vma:            Hint    Time      Forward  DLL       First
> 	DLL Name: bcrypt.dll
> 	DLL Name: KERNEL32.dll
> 	DLL Name: api-ms-win-crt-conio-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-convert-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-environment-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-filesystem-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-heap-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-locale-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-math-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-private-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-runtime-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-stdio-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-string-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-time-l1-1-0.dll
> 	DLL Name: api-ms-win-crt-utility-l1-1-0.dll
> 	DLL Name: USER32.dll
> 	DLL Name: WS2_32.dll
> 
> So I am not an expert in this area, and I have not tried to run this on a
> native XP machine, but somehow I wonder if defining _WIN32_WINNT to 0x501
> does still do the trick that makes it execute on Windows XP ?

It does, I actually run GDB on Windows XP.  GDB will run on XP as long
as you don't link it against the new UCRT runtime, but against the
original MSVCRT runtime.  The above dependency DLLs seem to indicate
that your link is against UCRT, I think.  MinGW64 currently supports
both MSVCRT and UCRT builds, and mingw.org's MinGW supports only
MSVCRT.
  

> Date: Fri, 10 May 2024 20:03:32 +0100
> Cc: Bernd Edlinger <bernd.edlinger@hotmail.de>,
>  "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
> From: Pedro Alves <pedro@palves.net>
> 
> On 2024-05-10 18:24, Tom Tromey wrote:
> >>>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes:
> > 
> > Hannes> If you don't need XP support, can't you just define _WIN32_WINNT
> > Hannes> in CPPFLAGS?
> > 
> > Yeah, it seems possible.  Maybe the problem is that unless you remember
> > this (it seems pretty obscure), a mingw build with a newer version of
> > GCC is going to fail due to libstdc++ wanting an older version that
> > gdb's default.
> 
> Presumably, if you pass --enable-threading=yes, but then configure detects 
> threading can't work, the configure fails.  We could at least make the
> error mention that you need to set _WIN32_WINNT to at least 0x600 in CFLAGS.
> 
> FWIW, I looked at this a while ago, and saw that Cygwin's oldest supported version
> is Windows 8.1 (says so at https://www.cygwin.com/).
> 
> Many people using Windows gdb will use a Cygwin environment, or Msys2 (which is
> a Cygwin fork), or "git bash" (which is an Msys2 fork...), and those won't work
> on older Windows.

Cygwin and MSYS2 indeed won't run on older Windows, but programs they
create still can, if built with caution and don't use any APIs from
later versions without run-time checking (like we do).

> It's quite likely that number of people really really using
> current GDB (for anything productive) on older Windows versions is very reduced,
> if not approaching zero.

Emacs still supports Windows XP (and even older versions), so it is
important for us to be able to run the latest GDB on XP.
  

Am Freitag, 10. Mai 2024 um 19:24:21 MESZ hat Tom Tromey <tromey@adacore.com> Folgendes geschrieben:

> >>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes:
>
> Hannes> If you don't need XP support, can't you just define _WIN32_WINNT
> Hannes> in CPPFLAGS?
>
> Yeah, it seems possible.  Maybe the problem is that unless you remember
> this (it seems pretty obscure), a mingw build with a newer version of
> GCC is going to fail due to libstdc++ wanting an older version that
> gdb's default.

I don't understand, why would the mingw build fail in this case?


Hannes
  

>>>>> "Hannes" == Hannes Domani <ssbssa@yahoo.de> writes:

Hannes> If you don't need XP support, can't you just define _WIN32_WINNT
Hannes> in CPPFLAGS?

>> Yeah, it seems possible.  Maybe the problem is that unless you remember
>> this (it seems pretty obscure), a mingw build with a newer version of
>> GCC is going to fail due to libstdc++ wanting an older version that
>> gdb's default.

Hannes> I don't understand, why would the mingw build fail in this case?

I think the problem that was recently fixed was just this kind of
failure.  The problem here is that gdb sets _WIN32_WINNT to a value that
is too low -- libstdc++ assumes a higher value.  So, before the
configure patch (commit 45e83f86) landed, including <mutex> would cause
problems, because that header assumes _WIN32_WINNT >= 0x0600.

Tom
  

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> Once again, that change was not supposed to lower the value of
Eli> _WIN32_WINNT, only to raise it if by default it is lower than 0x0501.
Eli> If that's not what happens nowadays, I think we need to understand
Eli> why, and fix it so it doesn't lower the value.

The code is:

#if defined (__MINGW32__) || defined (__CYGWIN__)
# ifdef _WIN32_WINNT
#  if _WIN32_WINNT < 0x0602
#   undef _WIN32_WINNT
#   define _WIN32_WINNT 0x0602
#  endif
# else
#  define _WIN32_WINNT 0x0602
# endif
#endif	/* __MINGW32__ || __CYGWIN__ */


Probably at this point _WIN32_WINNT is not set and so it takes the else
branch.  I didn't really check this though.

However, I thought the point of this code was to set up a compilation
environment that was "XP-like" -- that is, require all later-than-XP
APIs to be discovered dynamically.

Tom
  

Hi Eli,

On 2024-05-11 07:20, Eli Zaretskii wrote:
>> From: Pedro Alves <pedro@palves.net>

> Cygwin and MSYS2 indeed won't run on older Windows, but programs they
> create still can, if built with caution and don't use any APIs from
> later versions without run-time checking (like we do).
> 
>> It's quite likely that number of people really really using
>> current GDB (for anything productive) on older Windows versions is very reduced,
>> if not approaching zero.
> 
> Emacs still supports Windows XP (and even older versions), so it is
> important for us to be able to run the latest GDB on XP.
> 

OOC, is there a reason GDB versions other than the latest wouldn't work for
that?

I don't plan on proposing bumping the minimal supported version currently,
as I don't recall it blocking anything, but I would like to understand that
constraint better, for if/when the time comes.
  

> Date: Mon, 13 May 2024 15:21:16 +0100
> Cc: tromey@adacore.com, ssbssa@yahoo.de, bernd.edlinger@hotmail.de,
>  gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> On 2024-05-11 07:20, Eli Zaretskii wrote:
> >> From: Pedro Alves <pedro@palves.net>
> 
> > Cygwin and MSYS2 indeed won't run on older Windows, but programs they
> > create still can, if built with caution and don't use any APIs from
> > later versions without run-time checking (like we do).
> > 
> >> It's quite likely that number of people really really using
> >> current GDB (for anything productive) on older Windows versions is very reduced,
> >> if not approaching zero.
> > 
> > Emacs still supports Windows XP (and even older versions), so it is
> > important for us to be able to run the latest GDB on XP.
> > 
> 
> OOC, is there a reason GDB versions other than the latest wouldn't work for
> that?

Well, the future support for non-stop on Windows is one reason.  Emacs
on Windows uses several threads, as you may or may not know.

Newer GCC versions used to compile Emacs are another reason: as DWARF
info emitted by GCC is enhanced, we need newer versions of GDB to
support that.

More generally, as long as GDB doesn't _have_ to drop XP, i.e., as
long as keeping it doesn't place a too significant burden on GDB
maintenance, I think we should not deliberately break it.

> I don't plan on proposing bumping the minimal supported version currently,
> as I don't recall it blocking anything, but I would like to understand that
> constraint better, for if/when the time comes.

I hope I provided at least some rationale for my opinions.  (They are
not constraints, not unless the entire team agrees that this is our
official policy.)
  

On 2024-05-13 16:36, Eli Zaretskii wrote:
>> Date: Mon, 13 May 2024 15:21:16 +0100
>> Cc: tromey@adacore.com, ssbssa@yahoo.de, bernd.edlinger@hotmail.de,
>>  gdb-patches@sourceware.org
>> From: Pedro Alves <pedro@palves.net>
>>
>> On 2024-05-11 07:20, Eli Zaretskii wrote:
>>>> From: Pedro Alves <pedro@palves.net>
>>
>>> Cygwin and MSYS2 indeed won't run on older Windows, but programs they
>>> create still can, if built with caution and don't use any APIs from
>>> later versions without run-time checking (like we do).
>>>
>>>> It's quite likely that number of people really really using
>>>> current GDB (for anything productive) on older Windows versions is very reduced,
>>>> if not approaching zero.
>>>
>>> Emacs still supports Windows XP (and even older versions), so it is
>>> important for us to be able to run the latest GDB on XP.
>>>
>>
>> OOC, is there a reason GDB versions other than the latest wouldn't work for
>> that?
> 
> Well, the future support for non-stop on Windows is one reason.  Emacs
> on Windows uses several threads, as you may or may not know.

That feature will only work on Windows 10 and above, so newer GDB will
work the same as older GDB on WinXP.

> 
> Newer GCC versions used to compile Emacs are another reason: as DWARF
> info emitted by GCC is enhanced, we need newer versions of GDB to
> support that.

OK, I can see that.

> 
> More generally, as long as GDB doesn't _have_ to drop XP, i.e., as
> long as keeping it doesn't place a too significant burden on GDB
> maintenance, I think we should not deliberately break it.

Agreed.

> 
>> I don't plan on proposing bumping the minimal supported version currently,
>> as I don't recall it blocking anything, but I would like to understand that
>> constraint better, for if/when the time comes.
> 
> I hope I provided at least some rationale for my opinions.  (They are
> not constraints, not unless the entire team agrees that this is our
> official policy.)
> 

Thanks for the clarification.
  

Pedro> I don't plan on proposing bumping the minimal supported version currently,
Pedro> as I don't recall it blocking anything, but I would like to understand that
Pedro> constraint better, for if/when the time comes.

The problem is that libstdc++ puts gdb in a bind.

On the one hand, gdb tries to support XP.
On the other hand, <thread> requires a newer version; and use of threads
is desirable.

Tom
  

On 2024-05-13 19:45, Tom Tromey wrote:
> Pedro> I don't plan on proposing bumping the minimal supported version currently,
> Pedro> as I don't recall it blocking anything, but I would like to understand that
> Pedro> constraint better, for if/when the time comes.
> 
> The problem is that libstdc++ puts gdb in a bind.
> 
> On the one hand, gdb tries to support XP.
> On the other hand, <thread> requires a newer version; and use of threads
> is desirable.

That is for the win32 threading model, right?

I just tried cross building a win32 mingw gdb using the posix thread model:

/home/pedro/gdb/src/configure \
    --disable-ld \
    --disable-binutils \
    --disable-gas \
    --disable-gold \
    --disable-nls \
    --build=x86_64-pc-linux-gnu \
    --host=i686-w64-mingw32 \
    --target=i686-w64-mingw32 \
    --disable-source-highlight \
    --with-static-standard-libraries \
    --with-gmp=/home/pedro/src/gmp/install-win32 \
    --with-mpfr=/home/pedro/src/mpfr/install-win32 \
    --with-expat=yes --with-libexpat-prefix=/home/pedro/src/expat/install-win32/ \
    --enable-threading \
    CC=i686-w64-mingw32-gcc-posix \
    CXX=i686-w64-mingw32-g++-posix \
    CFLAGS="-g3 -O0" \
    CXXFLAGS="-g3 -O0"

and I got:

 $ wine ./gdb -ex "maintenance show worker-threads" -q --batch
 The number of worker threads GDB can use is the default (currently 8).

I think this binary would work on WinXP, and it supports threads.

The 64-bit mingw gcc with win32 threading model that comes with Ubuntu 22.04 seems to
be too old to support threading OOTB even if I configure with -D_WIN32_WINNT=0x600
in CFLAGS/CXXFLAGS.  It's GCC 10 based.  I think I'd need at least GCC 14.

But I think you should be able to configure with 

    --enable-threading CFLAGS="-D_WIN32_WINNT=0x600" CXXFLAGS="-D_WIN32_WINNT=0x600"

and then threads will be enabled.  If this doesn't work (with GCC >= 14), then it seems
like a bug to me.

Also, "--enable-threading=yes" silently ends up with threading disabled if std::thread
doesn't work.  I think that's a bug.  If I explicitly request threading, and then
configure detects std::thread doesn't work, it should error out.  Other options work
that way, like e.g., the TUI checks for curses:

# Check whether we should enable the TUI, but only do so if we really
# can.
if test x"$enable_tui" != xno; then
  if test "$curses_found" != no; then
    CONFIG_OBS="$CONFIG_OBS \$(SUBDIR_TUI_OBS)"
    CONFIG_DEPS="$CONFIG_DEPS \$(SUBDIR_TUI_DEPS)"
    CONFIG_SRCS="$CONFIG_SRCS \$(SUBDIR_TUI_SRCS)"
    ENABLE_CFLAGS="$ENABLE_CFLAGS \$(SUBDIR_TUI_CFLAGS)"
  else
    if test x"$enable_tui" = xyes; then
      AC_MSG_ERROR([no enhanced curses library found; disable TUI])
    else
      AC_MSG_WARN([no enhanced curses library found; disabling TUI])
    fi
  fi
fi
  

> Date: Tue, 14 May 2024 15:20:18 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, ssbssa@yahoo.de, bernd.edlinger@hotmail.de,
>  gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> I just tried cross building a win32 mingw gdb using the posix thread model:
> 
> /home/pedro/gdb/src/configure \
>     --disable-ld \
>     --disable-binutils \
>     --disable-gas \
>     --disable-gold \
>     --disable-nls \
>     --build=x86_64-pc-linux-gnu \
>     --host=i686-w64-mingw32 \
>     --target=i686-w64-mingw32 \
>     --disable-source-highlight \
>     --with-static-standard-libraries \
>     --with-gmp=/home/pedro/src/gmp/install-win32 \
>     --with-mpfr=/home/pedro/src/mpfr/install-win32 \
>     --with-expat=yes --with-libexpat-prefix=/home/pedro/src/expat/install-win32/ \
>     --enable-threading \
>     CC=i686-w64-mingw32-gcc-posix \
>     CXX=i686-w64-mingw32-g++-posix \
>     CFLAGS="-g3 -O0" \
>     CXXFLAGS="-g3 -O0"
> 
> and I got:
> 
>  $ wine ./gdb -ex "maintenance show worker-threads" -q --batch
>  The number of worker threads GDB can use is the default (currently 8).
> 
> I think this binary would work on WinXP, and it supports threads.

I suggest that you try.  AFAIK, MinGW64 dropped XP support about 2 or
more years ago.  So a binary built with MinGW64 might not run on XP
for that reason.

I build GDB using mingw.org's MinGW, which does support XP (and older
versions as well), but its pthreads are a different matter -- I had
trouble with them and removed it from my system to avoid that.  Plus,
I'm not sure mingw.org's libstc++ supports <thread> if you build for
Posix threading (it definitely does NOT support <thread> for w32
threading).

So once again, we should actually try this before we conclude it's
possible.

> Also, "--enable-threading=yes" silently ends up with threading disabled if std::thread
> doesn't work.  I think that's a bug.  If I explicitly request threading, and then
> configure detects std::thread doesn't work, it should error out.

Agreed.
  

On 2024-05-14 18:02, Eli Zaretskii wrote:
>> Date: Tue, 14 May 2024 15:20:18 +0100
>> Cc: Eli Zaretskii <eliz@gnu.org>, ssbssa@yahoo.de, bernd.edlinger@hotmail.de,
>>  gdb-patches@sourceware.org
>> From: Pedro Alves <pedro@palves.net>
>>
>> I just tried cross building a win32 mingw gdb using the posix thread model:
>>
>> /home/pedro/gdb/src/configure \
>>     --disable-ld \
>>     --disable-binutils \
>>     --disable-gas \
>>     --disable-gold \
>>     --disable-nls \
>>     --build=x86_64-pc-linux-gnu \
>>     --host=i686-w64-mingw32 \
>>     --target=i686-w64-mingw32 \
>>     --disable-source-highlight \
>>     --with-static-standard-libraries \
>>     --with-gmp=/home/pedro/src/gmp/install-win32 \
>>     --with-mpfr=/home/pedro/src/mpfr/install-win32 \
>>     --with-expat=yes --with-libexpat-prefix=/home/pedro/src/expat/install-win32/ \
>>     --enable-threading \
>>     CC=i686-w64-mingw32-gcc-posix \
>>     CXX=i686-w64-mingw32-g++-posix \
>>     CFLAGS="-g3 -O0" \
>>     CXXFLAGS="-g3 -O0"
>>
>> and I got:
>>
>>  $ wine ./gdb -ex "maintenance show worker-threads" -q --batch
>>  The number of worker threads GDB can use is the default (currently 8).
>>
>> I think this binary would work on WinXP, and it supports threads.
> 
> I suggest that you try.  AFAIK, MinGW64 dropped XP support about 2 or
> more years ago.  So a binary built with MinGW64 might not run on XP
> for that reason.
> 
> I build GDB using mingw.org's MinGW, which does support XP (and older
> versions as well), but its pthreads are a different matter -- I had
> trouble with them and removed it from my system to avoid that.  Plus,
> I'm not sure mingw.org's libstc++ supports <thread> if you build for
> Posix threading (it definitely does NOT support <thread> for w32
> threading).
> 
> So once again, we should actually try this before we conclude it's
> possible.

OK.  I will have to leave that for someone who actually has such a system.
I do not have one handy.

There is also this:

 https://github.com/meganz/mingw-std-threads

Described as:

"mingw-std-threads
 Implementation of standard C++11 threading classes, which are currently still missing on MinGW GCC.

 Target Windows version
 This implementation should work with Windows XP (regardless of service pack), or newer. The library automatically
 detects the version of Windows that is being targeted (at compile time), and selects an implementation that
 takes advantage of available Windows features. (...)."

> 
>> Also, "--enable-threading=yes" silently ends up with threading disabled if std::thread
>> doesn't work.  I think that's a bug.  If I explicitly request threading, and then
>> configure detects std::thread doesn't work, it should error out.
> 
> Agreed.
> 

I sent a patch for that, now:

https://inbox.sourceware.org/gdb-patches/20240514184341.1399428-1-pedro@palves.net/T/#u
  

> Date: Tue, 14 May 2024 19:47:48 +0100
> Cc: tromey@adacore.com, ssbssa@yahoo.de, bernd.edlinger@hotmail.de,
>  gdb-patches@sourceware.org
> From: Pedro Alves <pedro@palves.net>
> 
> > I build GDB using mingw.org's MinGW, which does support XP (and older
> > versions as well), but its pthreads are a different matter -- I had
> > trouble with them and removed it from my system to avoid that.  Plus,
> > I'm not sure mingw.org's libstc++ supports <thread> if you build for
> > Posix threading (it definitely does NOT support <thread> for w32
> > threading).
> > 
> > So once again, we should actually try this before we conclude it's
> > possible.
> 
> OK.  I will have to leave that for someone who actually has such a system.
> I do not have one handy.
> 
> There is also this:
> 
>  https://github.com/meganz/mingw-std-threads
> 
> Described as:
> 
> "mingw-std-threads
>  Implementation of standard C++11 threading classes, which are currently still missing on MinGW GCC.
> 
>  Target Windows version
>  This implementation should work with Windows XP (regardless of service pack), or newer. The library automatically
>  detects the version of Windows that is being targeted (at compile time), and selects an implementation that
>  takes advantage of available Windows features. (...)."

I know.  But AFAIR integrating it with libstdc++ is not a simple job,
and no one has done that yet.

> >> Also, "--enable-threading=yes" silently ends up with threading disabled if std::thread
> >> doesn't work.  I think that's a bug.  If I explicitly request threading, and then
> >> configure detects std::thread doesn't work, it should error out.
> > 
> > Agreed.
> > 
> 
> I sent a patch for that, now:
> 
> https://inbox.sourceware.org/gdb-patches/20240514184341.1399428-1-pedro@palves.net/T/#u

Thanks.