public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: i.nixman@autistici.org
To: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.org
Subject: Re: _WIN32_WINNT redefined?
Date: Wed, 02 Nov 2022 14:13:13 +0000	[thread overview]
Message-ID: <b9583b31c9c4061bf750b1331dc475ee@autistici.org> (raw)
In-Reply-To: <8335b1bjv2.fsf@gnu.org>

On 2022-11-02 12:50, Eli Zaretskii wrote:

Hello Eli!

I will try to explain step by step.


the root of the issue: GDB wan't build using MinGW-W64 toolchain uses 
this patch: 
https://gcc.gnu.org/pipermail/libstdc++/2022-October/054895.html
(for short, the patch provides the ability to libstdc++ to enable the 
support for std-threads and so on but without the need to use 
libwinpthreads: 
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/master/tree/mingw-w64-libraries/winpthreads/)

next, as I wrote earlier, I have faced with a trouble I can't build GDB 
using that path:
```
In file included from 
mingw64/lib/gcc/x86_64-w64-mingw32/13.0.0/include/c++/mutex:45,
                  from 
../src/gdb-11.2/gdbsupport/../gdbsupport/thread-pool.h:27,
                  from ../src/gdb-11.2/gdbsupport/thread-pool.cc:24:
mingw64/lib/gcc/x86_64-w64-mingw32/13.0.0/include/c++/bits/std_mutex.h:163:5: 
error: '__gthread_cond_t' does not name a type; did you mean 
'__gthread_once_t'?
   163 |     __gthread_cond_t* native_handle() noexcept { return 
&_M_cond; }
       |     ^~~~~~~~~~~~~~~~
```

because the patch requires the _WIN32_WINNT will be set to 0x0600 or 
greater.

next, GDB's building process trying to build `gdbsupport/thread-pool.cc` 
which includes `common-defs.h` first.
then, `gdbsupport/thread-pool.cc` includes `gdbsupport/thread-pool.h` 
which includes other standard headers like 
condition_variable/mutex/thread, etc.
at this point the inclusion chain looks like this: `mutex`[1] -> 
`bits/std_mutex.h`[2] -> `bits/gthr.h`[3] -> `gthr-default.h`[4]

[1] 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/mutex;h=b310c15687d323c1750f717e630fbe0666515139;hb=HEAD
[2] 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/std_mutex.h;h=b22e0e12793700291c65c1695313dbeae4561da2;hb=HEAD
[3] 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/gthr.h;h=7943c94f6d16b7aed4269aa08db746ae131430b1;hb=HEAD
(note for this link: in reality that file located inside gcc sources as 
`libgcc/gthr.h`, but on target toolchain it is `bits/gthr.h` without any 
changes)
[4] https://pastebin.com/LbE0qbwu
(note for this link: I paste that file on pastebin because I want to 
show you how looks that file after applying the patch)

now look at the 4 link at line 65: `#if _WIN32_WINNT >= 0x0600`
that is, in this case the definition from within the GDB sources 
"infects" the GCC sources. do you agree that this should not be the 
case?

well, back to the root.
please look at `gdbsupport/common-defs.h`: 
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdbsupport/common-defs.h;h=e4985332e3f4016ccec2b2502dfe28bab16e2c92;hb=HEAD

you may not believe me, but none of the inclusions above that 
preprocessor block I'm talking about include neither `windows.h` nor 
`winver.h` nothing that could tell to that preprocessor block the value 
of `_WIN32_WINNT` :)

thus, it turns out that that preprocessor block of code does not check 
and does not correct the value of `_WIN32_WINNT` but simply always 
imposes its value.


as solution I see two ways:
1) to remove that PP block completely, because as I wrote earlier - no 
one in the GDB sources refers to it.
2) to hide that PP block so that it cannot "infect" other code by by 
getting into public headers.





best!

  reply	other threads:[~2022-11-02 14:13 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-02  8:14 i.nixman
2022-11-02  8:21 ` i.nixman
2022-11-02  8:44   ` i.nixman
2022-11-02  9:46     ` i.nixman
2022-11-02 10:15       ` i.nixman
2022-11-02 12:59         ` Eli Zaretskii
2022-11-02 13:10           ` Jeffrey Walton
2022-11-02 13:26             ` Eli Zaretskii
2022-11-02 12:50       ` Eli Zaretskii
2022-11-02 14:13         ` i.nixman [this message]
2022-11-02 15:18           ` Eli Zaretskii
2022-11-02 15:51             ` i.nixman
2022-11-02 16:02               ` i.nixman
2022-11-02 16:51               ` Eli Zaretskii
2022-11-02 17:20                 ` i.nixman
2022-11-02 18:13                   ` Eli Zaretskii
2022-11-02 12:55     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b9583b31c9c4061bf750b1331dc475ee@autistici.org \
    --to=i.nixman@autistici.org \
    --cc=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).