[PATCH 1/3] gdb, gdbserver, gdbsupport: reformat some Makefile variables, one entry per line

[PATCH 1/3] gdb, gdbserver, gdbsupport: reformat some Makefile variables, one entry per line

[Simon Marchi]

Reformat some variables that the subsequent patches are going to touch.
I think it makes them easier to read, and it also makes diffs clearer.

Change-Id: I82f63ba0e6d0fe268eb1f1ad5ab22c3cd016ab02
---
 gdb/Makefile.in        |  8 ++++++--
 gdbserver/Makefile.in  | 12 +++++++++---
 gdbsupport/Makefile.am | 15 +++++++++++----
 3 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index 331620375aed..95709ae395a2 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
@@ -601,8 +601,12 @@ CONFIG_DEP_SUBDIR = $(addsuffix /$(DEPDIR),$(CONFIG_SRC_SUBDIR))
 # your system doesn't have fcntl.h in /usr/include (which is where it
 # should be according to Posix).
 DEFS = @DEFS@
-GDB_CFLAGS = -I. -I$(srcdir) -I$(srcdir)/config \
-	-DLOCALEDIR="\"$(localedir)\"" $(DEFS)
+GDB_CFLAGS = \
+	-I. \
+	-I$(srcdir) \
+	-I$(srcdir)/config \
+	-DLOCALEDIR="\"$(localedir)\"" \
+	$(DEFS)
 
 # MH_CFLAGS, if defined, has host-dependent CFLAGS from the config directory.
 GLOBAL_CFLAGS = $(MH_CFLAGS)
diff --git a/gdbserver/Makefile.in b/gdbserver/Makefile.in
index c7120895a26d..c17a0a522df2 100644
--- a/gdbserver/Makefile.in
+++ b/gdbserver/Makefile.in
@@ -125,9 +125,15 @@ INCSUPPORT = -I$(srcdir)/.. -I..
 # in those directories should be included with the subdirectory.
 # e.g.: "target/wait.h".
 #
-INCLUDE_CFLAGS = -I. -I${srcdir} \
-	-I$(srcdir)/../gdb/regformats -I$(srcdir)/.. -I$(INCLUDE_DIR) \
-	-I$(srcdir)/../gdb $(INCGNU) $(INCSUPPORT) \
+INCLUDE_CFLAGS = \
+	-I. \
+	-I${srcdir} \
+	-I$(srcdir)/../gdb/regformats \
+	-I$(srcdir)/.. \
+	-I$(INCLUDE_DIR) \
+	-I$(srcdir)/../gdb \
+	$(INCGNU) \
+	$(INCSUPPORT) \
 	$(INTL_CFLAGS)
 
 # M{H,T}_CFLAGS, if defined, has host- and target-dependent CFLAGS
diff --git a/gdbsupport/Makefile.am b/gdbsupport/Makefile.am
index 88414b4c927a..7c360aa413ef 100644
--- a/gdbsupport/Makefile.am
+++ b/gdbsupport/Makefile.am
@@ -25,10 +25,17 @@ ACLOCAL_AMFLAGS = -I . -I ../config
 # ZW_GNU_GETTEXT_SISTER_DIR, but doesn't have any translations (currently).
 SUBDIRS =
 
-AM_CPPFLAGS = -I$(srcdir)/../include -I$(srcdir)/../gdb \
-    -I../gnulib/import -I$(srcdir)/../gnulib/import \
-    -I.. -I$(srcdir)/.. $(INCINTL) -I../bfd -I$(srcdir)/../bfd \
-    @LARGEFILE_CPPFLAGS@
+AM_CPPFLAGS = \
+	-I$(srcdir)/../include \
+	-I$(srcdir)/../gdb \
+	-I../gnulib/import \
+	-I$(srcdir)/../gnulib/import \
+	-I.. \
+	-I$(srcdir)/.. \
+	$(INCINTL) \
+	-I../bfd \
+	-I$(srcdir)/../bfd \
+	@LARGEFILE_CPPFLAGS@
 
 override CXX += $(CXX_DIALECT)
 

base-commit: 0273b5967e21404d0442273b189b0e275cfafa74
-- 
2.44.0

[PATCH 2/3] gdb, gdbserver, gdbsupport: include config.h files with -include

[Simon Marchi]

The motivation for this change is for analysis tools and IDEs to be
better at analyzing header files on their own.

There are some definitions and includes we want to occur at the very
beginning of all translation units.  The way we currently do that is by
requiring all source files (.c and .cc files) to include one of defs.h
(for gdb), server.h (for gdbserver) of common-defs.h (for gdbsupport and
shared source files).  These special header files define and include
everything that needs to be included at the very beginning.  Other
header files are written in a way that assume that these special
"prologue" header files have already been included.

My problem with that is that my editor (clangd-based) provides a very
bad experience when editing source files.  Since clangd doesn't know
that one of defs.h/server.h/common-defs.h was included already, a lot of
things are flagged as errors.  For instance, CORE_ADDR is not known.
It's possible to edit the files in this state, but a lot of the power of
the editor is unavailable.

My proposal to help with this is to include those things we always want
to be there using the compilers' `-include` option.  Tom Tromey said
that the current approach might exist because not all compilers used to
have an option like this.  But I believe that it's safe to assume they
do today.

With this change, clangd picks up the -include option from the compile
command, and is able to analyze the header file correctly, as it sees
all that stuff included or defined but that -include option.  That works
because when editing a header file, clangd tries to get the compilation
flags from a source file that includes said header file.

This change is a bit, because it addresses one of my frustrations when
editing header files, but it might help others too.  I'd be curious to
know if others encounter the same kinds of problems when editing header
files.  Also, even if the change is not necessary by any means, I think
the solution of using -include for stuff we always want to be there is
more elegant than the current solution.

Even with this -include flag, many header files currently don't include
what they use, but rather depend on files included before them.  This
will still cause errors when editing them, but it should be easily
fixable by adding the appropriate include.  There's no rush to do so, as
long as the code still copiles, it's just a convenience thing.

This patch does the small step of moving the inclusion of the various
config.h files to that new method.  The changes are:

 - Add three files meant to be included with -include: gdb/gdb.inc.h,
   gdbserver/gdbserver.inc.h and gdbsupport/gdbsupport.inc.h.
 - Move the inclusion of the various config.h files there
 - Modify the compilation flags of all three subdirectories to add the
   appropriate -include option.

Change-Id: If3e345d00a9fc42336322f1d8286687d22134340
---
 gdb/Makefile.in             |  1 +
 gdb/defs.h                  |  7 -------
 gdb/gdb.inc.h               | 22 ++++++++++++++++++++++
 gdbserver/Makefile.in       |  3 ++-
 gdbserver/gdbserver.inc.h   | 22 ++++++++++++++++++++++
 gdbserver/server.h          |  8 --------
 gdbsupport/Makefile.am      |  1 +
 gdbsupport/Makefile.in      | 16 ++++++++++++----
 gdbsupport/common-defs.h    | 10 ----------
 gdbsupport/gdbsupport.inc.h | 35 +++++++++++++++++++++++++++++++++++
 10 files changed, 95 insertions(+), 30 deletions(-)
 create mode 100644 gdb/gdb.inc.h
 create mode 100644 gdbserver/gdbserver.inc.h
 create mode 100644 gdbsupport/gdbsupport.inc.h

diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index 95709ae395a2..3b144fa3034c 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
@@ -605,6 +605,7 @@ GDB_CFLAGS = \
 	-I. \
 	-I$(srcdir) \
 	-I$(srcdir)/config \
+	-include $(srcdir)/gdb.inc.h \
 	-DLOCALEDIR="\"$(localedir)\"" \
 	$(DEFS)
 
diff --git a/gdb/defs.h b/gdb/defs.h
index cf471bf5d662..8a9ff3aba0f7 100644
--- a/gdb/defs.h
+++ b/gdb/defs.h
@@ -25,13 +25,6 @@
 
 #include "gdbsupport/common-defs.h"
 
-#undef PACKAGE
-#undef PACKAGE_NAME
-#undef PACKAGE_VERSION
-#undef PACKAGE_STRING
-#undef PACKAGE_TARNAME
-
-#include <config.h>
 #include "bfd.h"
 
 #include <sys/types.h>
diff --git a/gdb/gdb.inc.h b/gdb/gdb.inc.h
new file mode 100644
index 000000000000..7be4c8eea939
--- /dev/null
+++ b/gdb/gdb.inc.h
@@ -0,0 +1,22 @@
+/* Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+/* This file in included automatically via `-include` at the beginning of each
+   source file compiled in gdb/.  */
+
+#include "gdbsupport/gdbsupport.inc.h"
+#include "config.h"
diff --git a/gdbserver/Makefile.in b/gdbserver/Makefile.in
index c17a0a522df2..c92b881650a4 100644
--- a/gdbserver/Makefile.in
+++ b/gdbserver/Makefile.in
@@ -134,7 +134,8 @@ INCLUDE_CFLAGS = \
 	-I$(srcdir)/../gdb \
 	$(INCGNU) \
 	$(INCSUPPORT) \
-	$(INTL_CFLAGS)
+	$(INTL_CFLAGS) \
+	-include $(srcdir)/gdbserver.inc.h
 
 # M{H,T}_CFLAGS, if defined, has host- and target-dependent CFLAGS
 # from the config/ directory.
diff --git a/gdbserver/gdbserver.inc.h b/gdbserver/gdbserver.inc.h
new file mode 100644
index 000000000000..22ec0dd94318
--- /dev/null
+++ b/gdbserver/gdbserver.inc.h
@@ -0,0 +1,22 @@
+/* Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+/* This file in included automatically via `-include` at the beginning of each
+   source file compiled in gdbserver/.  */
+
+#include "gdbsupport/gdbsupport.inc.h"
+#include "config.h"
diff --git a/gdbserver/server.h b/gdbserver/server.h
index 0074818c6df0..ee27d2b3f5c2 100644
--- a/gdbserver/server.h
+++ b/gdbserver/server.h
@@ -21,14 +21,6 @@
 
 #include "gdbsupport/common-defs.h"
 
-#undef PACKAGE
-#undef PACKAGE_NAME
-#undef PACKAGE_VERSION
-#undef PACKAGE_STRING
-#undef PACKAGE_TARNAME
-
-#include <config.h>
-
 static_assert (sizeof (CORE_ADDR) >= sizeof (void *));
 
 #include "gdbsupport/version.h"
diff --git a/gdbsupport/Makefile.am b/gdbsupport/Makefile.am
index 7c360aa413ef..db1eee88059a 100644
--- a/gdbsupport/Makefile.am
+++ b/gdbsupport/Makefile.am
@@ -35,6 +35,7 @@ AM_CPPFLAGS = \
 	$(INCINTL) \
 	-I../bfd \
 	-I$(srcdir)/../bfd \
+	-include $(srcdir)/gdbsupport.inc.h \
 	@LARGEFILE_CPPFLAGS@
 
 override CXX += $(CXX_DIALECT)
diff --git a/gdbsupport/Makefile.in b/gdbsupport/Makefile.in
index 6f8dacc157f9..9b1063f31ab3 100644
--- a/gdbsupport/Makefile.in
+++ b/gdbsupport/Makefile.in
@@ -393,10 +393,18 @@ ACLOCAL_AMFLAGS = -I . -I ../config
 # from Automake, as gdbsupport uses AM_GNU_GETTEXT through
 # ZW_GNU_GETTEXT_SISTER_DIR, but doesn't have any translations (currently).
 SUBDIRS = 
-AM_CPPFLAGS = -I$(srcdir)/../include -I$(srcdir)/../gdb \
-    -I../gnulib/import -I$(srcdir)/../gnulib/import \
-    -I.. -I$(srcdir)/.. $(INCINTL) -I../bfd -I$(srcdir)/../bfd \
-    @LARGEFILE_CPPFLAGS@
+AM_CPPFLAGS = \
+	-I$(srcdir)/../include \
+	-I$(srcdir)/../gdb \
+	-I../gnulib/import \
+	-I$(srcdir)/../gnulib/import \
+	-I.. \
+	-I$(srcdir)/.. \
+	$(INCINTL) \
+	-I../bfd \
+	-I$(srcdir)/../bfd \
+	-include $(srcdir)/gdbsupport.inc.h \
+	@LARGEFILE_CPPFLAGS@
 
 AM_CXXFLAGS = $(WARN_CFLAGS) $(WERROR_CFLAGS)
 noinst_LIBRARIES = libgdbsupport.a
diff --git a/gdbsupport/common-defs.h b/gdbsupport/common-defs.h
index 6120719480b8..e7eb814f3251 100644
--- a/gdbsupport/common-defs.h
+++ b/gdbsupport/common-defs.h
@@ -20,16 +20,6 @@
 #ifndef COMMON_COMMON_DEFS_H
 #define COMMON_COMMON_DEFS_H
 
-#include <gdbsupport/config.h>
-
-#undef PACKAGE_NAME
-#undef PACKAGE
-#undef PACKAGE_VERSION
-#undef PACKAGE_STRING
-#undef PACKAGE_TARNAME
-
-#include "gnulib/config.h"
-
 /* From:
     https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
 
diff --git a/gdbsupport/gdbsupport.inc.h b/gdbsupport/gdbsupport.inc.h
new file mode 100644
index 000000000000..ab0999579528
--- /dev/null
+++ b/gdbsupport/gdbsupport.inc.h
@@ -0,0 +1,35 @@
+/* Copyright (C) 2024 Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+/* This file in included automatically via `-include` at the beginning of each
+   source file compiled in gdbsupport/.  */
+
+#include "gdbsupport/config.h"
+
+#undef PACKAGE
+#undef PACKAGE_NAME
+#undef PACKAGE_STRING
+#undef PACKAGE_TARNAME
+#undef PACKAGE_VERSION
+
+#include "gnulib/config.h"
+
+#undef PACKAGE
+#undef PACKAGE_NAME
+#undef PACKAGE_STRING
+#undef PACKAGE_TARNAME
+#undef PACKAGE_VERSION
-- 
2.44.0

Re: [PATCH 2/3] gdb, gdbserver, gdbsupport: include config.h files with -include

[Hannes Domani]

 Am Montag, 18. März 2024 um 21:03:47 MEZ hat Simon Marchi <simon.marchi@efficios.com> Folgendes geschrieben:

> diff --git a/gdbsupport/Makefile.am b/gdbsupport/Makefile.am
> index 7c360aa413ef..db1eee88059a 100644
> --- a/gdbsupport/Makefile.am
> +++ b/gdbsupport/Makefile.am
> @@ -35,6 +35,7 @@ AM_CPPFLAGS = \
>     $(INCINTL) \
>     -I../bfd \
>     -I$(srcdir)/../bfd \
> +    -include $(srcdir)/gdbsupport.inc.h \
>     @LARGEFILE_CPPFLAGS@
>
> override CXX += $(CXX_DIALECT)
> diff --git a/gdbsupport/Makefile.in b/gdbsupport/Makefile.in
> index 6f8dacc157f9..9b1063f31ab3 100644
> --- a/gdbsupport/Makefile.in
> +++ b/gdbsupport/Makefile.in
> @@ -393,10 +393,18 @@ ACLOCAL_AMFLAGS = -I . -I ../config
> # from Automake, as gdbsupport uses AM_GNU_GETTEXT through
> # ZW_GNU_GETTEXT_SISTER_DIR, but doesn't have any translations (currently).
> SUBDIRS =
> -AM_CPPFLAGS = -I$(srcdir)/../include -I$(srcdir)/../gdb \
> -    -I../gnulib/import -I$(srcdir)/../gnulib/import \
> -    -I.. -I$(srcdir)/.. $(INCINTL) -I../bfd -I$(srcdir)/../bfd \
> -    @LARGEFILE_CPPFLAGS@
> +AM_CPPFLAGS = \
> +    -I$(srcdir)/../include \
> +    -I$(srcdir)/../gdb \
> +    -I../gnulib/import \
> +    -I$(srcdir)/../gnulib/import \
> +    -I.. \
> +    -I$(srcdir)/.. \
> +    $(INCINTL) \
> +    -I../bfd \
> +    -I$(srcdir)/../bfd \
> +    -include $(srcdir)/gdbsupport.inc.h \
> +    @LARGEFILE_CPPFLAGS@
>
> AM_CXXFLAGS = $(WARN_CFLAGS) $(WERROR_CFLAGS)
> noinst_LIBRARIES = libgdbsupport.a

Shouldn't most of this hunk be in the 'one entry per line' commit?


Hannes

Re: [PATCH 2/3] gdb, gdbserver, gdbsupport: include config.h files with -include

[Simon Marchi]

On 3/19/24 07:18, Hannes Domani wrote:
>  Am Montag, 18. März 2024 um 21:03:47 MEZ hat Simon Marchi <simon.marchi@efficios.com> Folgendes geschrieben:
> 
>> diff --git a/gdbsupport/Makefile.am b/gdbsupport/Makefile.am
>> index 7c360aa413ef..db1eee88059a 100644
>> --- a/gdbsupport/Makefile.am
>> +++ b/gdbsupport/Makefile.am
>> @@ -35,6 +35,7 @@ AM_CPPFLAGS = \
>>      $(INCINTL) \
>>      -I../bfd \
>>      -I$(srcdir)/../bfd \
>> +    -include $(srcdir)/gdbsupport.inc.h \
>>      @LARGEFILE_CPPFLAGS@
>>
>> override CXX += $(CXX_DIALECT)
>> diff --git a/gdbsupport/Makefile.in b/gdbsupport/Makefile.in
>> index 6f8dacc157f9..9b1063f31ab3 100644
>> --- a/gdbsupport/Makefile.in
>> +++ b/gdbsupport/Makefile.in
>> @@ -393,10 +393,18 @@ ACLOCAL_AMFLAGS = -I . -I ../config
>> # from Automake, as gdbsupport uses AM_GNU_GETTEXT through
>> # ZW_GNU_GETTEXT_SISTER_DIR, but doesn't have any translations (currently).
>> SUBDIRS =
>> -AM_CPPFLAGS = -I$(srcdir)/../include -I$(srcdir)/../gdb \
>> -    -I../gnulib/import -I$(srcdir)/../gnulib/import \
>> -    -I.. -I$(srcdir)/.. $(INCINTL) -I../bfd -I$(srcdir)/../bfd \
>> -    @LARGEFILE_CPPFLAGS@
>> +AM_CPPFLAGS = \
>> +    -I$(srcdir)/../include \
>> +    -I$(srcdir)/../gdb \
>> +    -I../gnulib/import \
>> +    -I$(srcdir)/../gnulib/import \
>> +    -I.. \
>> +    -I$(srcdir)/.. \
>> +    $(INCINTL) \
>> +    -I../bfd \
>> +    -I$(srcdir)/../bfd \
>> +    -include $(srcdir)/gdbsupport.inc.h \
>> +    @LARGEFILE_CPPFLAGS@
>>
>> AM_CXXFLAGS = $(WARN_CFLAGS) $(WERROR_CFLAGS)
>> noinst_LIBRARIES = libgdbsupport.a
> 
> Shouldn't most of this hunk be in the 'one entry per line' commit?

Ah yeah, I was missing regenerating gdbsupport/Makefile.in in the first
patch.  Fixed locally.  Thanks for pointing it out.

Simon

Re: [PATCH 2/3] gdb, gdbserver, gdbsupport: include config.h files with -include

[Pedro Alves]

On 2024-03-18 20:01, Simon Marchi wrote:
> The motivation for this change is for analysis tools and IDEs to be
> better at analyzing header files on their own.
> 
> There are some definitions and includes we want to occur at the very
> beginning of all translation units.  The way we currently do that is by
> requiring all source files (.c and .cc files) to include one of defs.h
> (for gdb), server.h (for gdbserver) of common-defs.h (for gdbsupport and
> shared source files).  These special header files define and include
> everything that needs to be included at the very beginning.  Other
> header files are written in a way that assume that these special
> "prologue" header files have already been included.
> 
> My problem with that is that my editor (clangd-based) provides a very
> bad experience when editing source files.  

I think you meant "when editing header files."

> Since clangd doesn't know
> that one of defs.h/server.h/common-defs.h was included already, a lot of
> things are flagged as errors.  For instance, CORE_ADDR is not known.
> It's possible to edit the files in this state, but a lot of the power of
> the editor is unavailable.
> 
> My proposal to help with this is to include those things we always want
> to be there using the compilers' `-include` option.  Tom Tromey said
> that the current approach might exist because not all compilers used to
> have an option like this.  But I believe that it's safe to assume they
> do today.
> 
> With this change, clangd picks up the -include option from the compile
> command, and is able to analyze the header file correctly, as it sees
> all that stuff included or defined but that -include option.  That works
> because when editing a header file, clangd tries to get the compilation
> flags from a source file that includes said header file.
> 
> This change is a bit, because it addresses one of my frustrations when

This change is a bit ______? (fill in missing word).


> editing header files, but it might help others too.  I'd be curious to
> know if others encounter the same kinds of problems when editing header
> files.  Also, even if the change is not necessary by any means, I think
> the solution of using -include for stuff we always want to be there is
> more elegant than the current solution.
> 
> Even with this -include flag, many header files currently don't include
> what they use, but rather depend on files included before them.  This
> will still cause errors when editing them, but it should be easily
> fixable by adding the appropriate include.  There's no rush to do so, as
> long as the code still copiles, it's just a convenience thing.

copiles -> compiles


Note there is a make rule to check whether gdb headers are standalone.  "make check-headers".
Unfortunately, nobody ever runs that ( me included, after adding it a decade ago :-P ).
Ideally, we'd fix all it flags and run it (or something like it) once in a while in a CI.
(And same for gdbserver/gdbsupport, of course.)


> 
> This patch does the small step of moving the inclusion of the various
> config.h files to that new method.  The changes are:
> 
>  - Add three files meant to be included with -include: gdb/gdb.inc.h,
>    gdbserver/gdbserver.inc.h and gdbsupport/gdbsupport.inc.h.
>  - Move the inclusion of the various config.h files there
>  - Modify the compilation flags of all three subdirectories to add the
>    appropriate -include option.

I'm surprised by the actual patch.  Why isn't this including defs.h/common-defs.h?  There are
surely things defined in those files that need to be defined in headers too.  Why create
this divergence?  I'd think that we would include defs.h/common-defs.h in headers too, and
then work on moving things out of defs.h/common-defs.h over time.

Pedro Alves

Re: [PATCH 2/3] gdb, gdbserver, gdbsupport: include config.h files with -include

[Simon Marchi]

On 3/20/24 16:32, Pedro Alves wrote:
> On 2024-03-18 20:01, Simon Marchi wrote:
>> The motivation for this change is for analysis tools and IDEs to be
>> better at analyzing header files on their own.
>>
>> There are some definitions and includes we want to occur at the very
>> beginning of all translation units.  The way we currently do that is by
>> requiring all source files (.c and .cc files) to include one of defs.h
>> (for gdb), server.h (for gdbserver) of common-defs.h (for gdbsupport and
>> shared source files).  These special header files define and include
>> everything that needs to be included at the very beginning.  Other
>> header files are written in a way that assume that these special
>> "prologue" header files have already been included.
>>
>> My problem with that is that my editor (clangd-based) provides a very
>> bad experience when editing source files.  
> 
> I think you meant "when editing header files."

Oops, yes.  Fixed.

>> Since clangd doesn't know
>> that one of defs.h/server.h/common-defs.h was included already, a lot of
>> things are flagged as errors.  For instance, CORE_ADDR is not known.
>> It's possible to edit the files in this state, but a lot of the power of
>> the editor is unavailable.
>>
>> My proposal to help with this is to include those things we always want
>> to be there using the compilers' `-include` option.  Tom Tromey said
>> that the current approach might exist because not all compilers used to
>> have an option like this.  But I believe that it's safe to assume they
>> do today.
>>
>> With this change, clangd picks up the -include option from the compile
>> command, and is able to analyze the header file correctly, as it sees
>> all that stuff included or defined but that -include option.  That works
>> because when editing a header file, clangd tries to get the compilation
>> flags from a source file that includes said header file.
>>
>> This change is a bit, because it addresses one of my frustrations when
> 
> This change is a bit ______? (fill in missing word).

Oops again.  I meant "This change is a bit self-serving".

>> editing header files, but it might help others too.  I'd be curious to
>> know if others encounter the same kinds of problems when editing header
>> files.  Also, even if the change is not necessary by any means, I think
>> the solution of using -include for stuff we always want to be there is
>> more elegant than the current solution.
>>
>> Even with this -include flag, many header files currently don't include
>> what they use, but rather depend on files included before them.  This
>> will still cause errors when editing them, but it should be easily
>> fixable by adding the appropriate include.  There's no rush to do so, as
>> long as the code still copiles, it's just a convenience thing.
> 
> copiles -> compiles

Fixed.

> Note there is a make rule to check whether gdb headers are standalone.  "make check-headers".
> Unfortunately, nobody ever runs that ( me included, after adding it a decade ago :-P ).
> Ideally, we'd fix all it flags and run it (or something like it) once in a while in a CI.
> (And same for gdbserver/gdbsupport, of course.)

Ah! I probably saw that in the past but forgot about it.  It might need
to be changed too, depending on what follows.

>> This patch does the small step of moving the inclusion of the various
>> config.h files to that new method.  The changes are:
>>
>>  - Add three files meant to be included with -include: gdb/gdb.inc.h,
>>    gdbserver/gdbserver.inc.h and gdbsupport/gdbsupport.inc.h.
>>  - Move the inclusion of the various config.h files there
>>  - Modify the compilation flags of all three subdirectories to add the
>>    appropriate -include option.
> 
> I'm surprised by the actual patch.  Why isn't this including defs.h/common-defs.h?  There are
> surely things defined in those files that need to be defined in headers too.  Why create
> this divergence?  I'd think that we would include defs.h/common-defs.h in headers too, and
> then work on moving things out of defs.h/common-defs.h over time.

I am not sure I understand what you mean.  If a given header file uses
something defined in defs.h, then it should include defs.h.  Otherwise
it doesn't need to.  Maybe if you give a concrete example I will get
your point better.

Simon

Re: [PATCH 2/3] gdb, gdbserver, gdbsupport: include config.h files with -include

[Pedro Alves]

On 2024-03-21 02:11, Simon Marchi wrote:
> On 3/20/24 16:32, Pedro Alves wrote:
>> On 2024-03-18 20:01, Simon Marchi wrote:
>> Note there is a make rule to check whether gdb headers are standalone.  "make check-headers".
>> Unfortunately, nobody ever runs that ( me included, after adding it a decade ago :-P ).
>> Ideally, we'd fix all it flags and run it (or something like it) once in a while in a CI.
>> (And same for gdbserver/gdbsupport, of course.)
> 
> Ah! I probably saw that in the past but forgot about it.  It might need
> to be changed too, depending on what follows.
> 
>>> This patch does the small step of moving the inclusion of the various
>>> config.h files to that new method.  The changes are:
>>>
>>>  - Add three files meant to be included with -include: gdb/gdb.inc.h,
>>>    gdbserver/gdbserver.inc.h and gdbsupport/gdbsupport.inc.h.
>>>  - Move the inclusion of the various config.h files there
>>>  - Modify the compilation flags of all three subdirectories to add the
>>>    appropriate -include option.
>>
>> I'm surprised by the actual patch.  Why isn't this including defs.h/common-defs.h?  There are
>> surely things defined in those files that need to be defined in headers too.  Why create
>> this divergence?  I'd think that we would include defs.h/common-defs.h in headers too, and
>> then work on moving things out of defs.h/common-defs.h over time.
> 
> I am not sure I understand what you mean.  If a given header file uses
> something defined in defs.h, then it should include defs.h.  Otherwise
> it doesn't need to.  Maybe if you give a concrete example I will get
> your point better.
> 

I think you're looking at this all backwards, TBH.  

Currently, defs.h (and common-defs.h/server.h...) is a special header, and we need to include it first.

We all agree that defs.h includes too much, and that several things in it should be moved to other headers, and included
only where they're needed.  If we imagine we've already done that, then defs.h is left with only the things that
need to be included by all source files, and all headers.

That's the end goals that seems super obvious to me.

Yet, your patch takes a different route, and creates yet another set of special headers, and moves some things there.

It then leaves us in a partial transition state, where it's very likely that some headers needed more things that are
included by defs.h, but they aren't included in the new magic header, nor in the said headers that needed the things.
I.e., it likely regresses "make check-headers" even further.  Some headers use bfd_vma for example.  Are they all including
libbfd.h explicitly or transitively?  I don't know.  Currently they get it from defs.h.  Some headers make use
of "enum block_enum", which is defined in defs.h today, so when you edit such headers you'll will not have that
enum defined.  Likewise probably other enums in defs.h.  We use gdb::array_view in a lot of headers, etc.

I really see no reason for the new headers, and switching to a different set of magic headers, and moving things around
from defs.h to the new headers.  It makes me a bit nervous even, as order of some things in defs.h (and friends) is important.
E.g., the GCC_GENERATED_STDINT_H thing.

What I'm saying is that the patch that I was expecting to see, was one that simply does one thing -- makes gdb use "-include" to
force-include defs.h everywhere (and common-defs.h/server.h, you get the point).  It's then just one single, atomic, change.  We go
from having to put defs.h at the top of source files, to not having to do that because we use "-include defs.h".  That's it.  Nothing more.
So defs.h is still the same special header, just the mechanism by which we include it changes.  The code that ends up compiled is
_exactly_ the same.  Documentation explaining that that is the special header doesn't have to change.

And your use case, editing the header, will end up with headers including _exactly_ what they include today when any source
file is compiled, not some subset of defs.h.  Any oddity with editing the file is an oddity normal compilation would have too.

And then, over time, we move things out of defs.h.  E.g., move to including array-view.h in headers that need it.  Move
the definitions of enum block_enum, enum user_selected_what_flag, etc. to some other headers that make more sense.  Move the inline
functions and function prototypes to other headers.  Etc.  But we take it from the top down.  Ultimately still end up with defs.h,
but a smaller defs.h.  

And at each step of the way, editing a header file always sees the exact same set of pre-included files/symbols as when the same header
is compiled normally.

Pedro Alves

Re: [PATCH 2/3] gdb, gdbserver, gdbsupport: include config.h files with -include

[Pedro Alves]

On 2024-03-21 12:50, Pedro Alves wrote:
> And at each step of the way, editing a header file always sees the exact
>  same set of pre-included files/symbols as when the same header
> is compiled normally.

Let me clarify this.  Here I was generally referring to the rule that source files should include their
module header right after defs.h.  Like:

 foo.c:
 #include "defs.h"
 #include "foo.h"
 * other includes *

So with that, there's one compilation unit that compiles "foo.h" exactly the same as what clangd sees when editing foo.h.

That even enforces "include what you need" in foo.h (other than the things defs.h already includes, of course).

We don't do that presently in many places, but we should do it throughout.  IIRC, Tromey even had a series to
normalize that throughout the tree a few years ago.  I don't recall why it didn't land.

Re: [PATCH 2/3] gdb, gdbserver, gdbsupport: include config.h files with -include

[Simon Marchi]

On 3/21/24 08:50, Pedro Alves wrote:
> On 2024-03-21 02:11, Simon Marchi wrote:
>> On 3/20/24 16:32, Pedro Alves wrote:
>>> On 2024-03-18 20:01, Simon Marchi wrote:
>>> Note there is a make rule to check whether gdb headers are standalone.  "make check-headers".
>>> Unfortunately, nobody ever runs that ( me included, after adding it a decade ago :-P ).
>>> Ideally, we'd fix all it flags and run it (or something like it) once in a while in a CI.
>>> (And same for gdbserver/gdbsupport, of course.)
>>
>> Ah! I probably saw that in the past but forgot about it.  It might need
>> to be changed too, depending on what follows.
>>
>>>> This patch does the small step of moving the inclusion of the various
>>>> config.h files to that new method.  The changes are:
>>>>
>>>>  - Add three files meant to be included with -include: gdb/gdb.inc.h,
>>>>    gdbserver/gdbserver.inc.h and gdbsupport/gdbsupport.inc.h.
>>>>  - Move the inclusion of the various config.h files there
>>>>  - Modify the compilation flags of all three subdirectories to add the
>>>>    appropriate -include option.
>>>
>>> I'm surprised by the actual patch.  Why isn't this including defs.h/common-defs.h?  There are
>>> surely things defined in those files that need to be defined in headers too.  Why create
>>> this divergence?  I'd think that we would include defs.h/common-defs.h in headers too, and
>>> then work on moving things out of defs.h/common-defs.h over time.
>>
>> I am not sure I understand what you mean.  If a given header file uses
>> something defined in defs.h, then it should include defs.h.  Otherwise
>> it doesn't need to.  Maybe if you give a concrete example I will get
>> your point better.
>>
> 
> I think you're looking at this all backwards, TBH.  

Thanks a lot for the feedback.  TLDR, I agree with you.

> 
> Currently, defs.h (and common-defs.h/server.h...) is a special header, and we need to include it first.
> 
> We all agree that defs.h includes too much, and that several things in it should be moved to other headers, and included
> only where they're needed.  If we imagine we've already done that, then defs.h is left with only the things that
> need to be included by all source files, and all headers.
> 
> That's the end goals that seems super obvious to me.
> 
> Yet, your patch takes a different route, and creates yet another set of special headers, and moves some things there.

To be clear, after my series, defs.h is no longer special.  It just
happens that headers that need it rely on it having been included
before.  I didn't see it as an immediate problem (it still builds),
because there are a lot more instances of that problem anyway (cases
that make check-headers would catch).  I saw it as something we would
fix little by little.

> It then leaves us in a partial transition state, where it's very likely that some headers needed more things that are
> included by defs.h, but they aren't included in the new magic header, nor in the said headers that needed the things.
> I.e., it likely regresses "make check-headers" even further.  Some headers use bfd_vma for example.  Are they all including
> libbfd.h explicitly or transitively?  I don't know.  Currently they get it from defs.h.  Some headers make use
> of "enum block_enum", which is defined in defs.h today, so when you edit such headers you'll will not have that
> enum defined.  Likewise probably other enums in defs.h.  We use gdb::array_view in a lot of headers, etc.

Right, my series doesn't actually make it better when I look at header.
But it makes it so the errors make sense, and I can start fixing them.
Whereas right now, the errors given in the headers sometimes don't make
sense, because we're missing some magic things from the various config.h
files, for instance.

> I really see no reason for the new headers, and switching to a different set of magic headers, and moving things around
> from defs.h to the new headers.  It makes me a bit nervous even, as order of some things in defs.h (and friends) is important.
> E.g., the GCC_GENERATED_STDINT_H thing.

My hope was that we could identify in one go all the stuff that needs to
be included or defined early, and put it in a new, clean header.  But
of course that's risky, it looks like GCC_GENERATED_STDINT_H would
belong in the early include file too.

> What I'm saying is that the patch that I was expecting to see, was one that simply does one thing -- makes gdb use "-include" to
> force-include defs.h everywhere (and common-defs.h/server.h, you get the point).  It's then just one single, atomic, change.  We go
> from having to put defs.h at the top of source files, to not having to do that because we use "-include defs.h".  That's it.  Nothing more.
> So defs.h is still the same special header, just the mechanism by which we include it changes.  The code that ends up compiled is
> _exactly_ the same.  Documentation explaining that that is the special header doesn't have to change.

I think that makes sense.  It's clearly less risky than my approach.  It
has the advantage that editing headers should work fine right away.

> And your use case, editing the header, will end up with headers including _exactly_ what they include today when any source
> file is compiled, not some subset of defs.h.  Any oddity with editing the file is an oddity normal compilation would have too.
> 
> And then, over time, we move things out of defs.h.  E.g., move to including array-view.h in headers that need it.  Move
> the definitions of enum block_enum, enum user_selected_what_flag, etc. to some other headers that make more sense.  Move the inline
> functions and function prototypes to other headers.  Etc.  But we take it from the top down.  Ultimately still end up with defs.h,
> but a smaller defs.h.  
> 
> And at each step of the way, editing a header file always sees the exact same set of pre-included files/symbols as when the same header
> is compiled normally.

Ack, thanks!

Simon

Re: [PATCH 2/3] gdb, gdbserver, gdbsupport: include config.h files with -include

[Simon Marchi]

On 3/22/24 10:55, Simon Marchi wrote:> Ack, thanks!
> 
> Simon

One question: files such as gdb/arch/arc.c currently include
gdbsupport/common-defs.h, since they are compiled separately in the gdb
and gdbserver context.  With my changes (even when I'll update my patch
to take the approach you suggest), the gdb-compiled version will use
`-include defs.h`, while the gdbserver-compiled version will use
`-include server.h`.  Both defs.h and server.h include common-defs.h, so
it works.  But is it a problem?  Should I modify the build system so
that these shared files use `-include gdbsupport/common-defs.h`?

Another (more involved) option would be to see if these files could get
moved to gdbsupport.

Simon

Re: [PATCH 2/3] gdb, gdbserver, gdbsupport: include config.h files with -include

[Pedro Alves]

On 2024-03-22 15:08, Simon Marchi wrote:
> On 3/22/24 10:55, Simon Marchi wrote:> Ack, thanks!
>>
>> Simon
> 
> One question: files such as gdb/arch/arc.c currently include
> gdbsupport/common-defs.h, since they are compiled separately in the gdb
> and gdbserver context.  With my changes (even when I'll update my patch
> to take the approach you suggest), the gdb-compiled version will use
> `-include defs.h`, while the gdbserver-compiled version will use
> `-include server.h`.  Both defs.h and server.h include common-defs.h, so
> it works.  But is it a problem?  Should I modify the build system so
> that these shared files use `-include gdbsupport/common-defs.h`?

I think we can go either way at this point, I don't think it's a real problem unless
we move the files to gdbsupport/.  Using common-defs.h helps a little with avoiding adding
gdb-only or gdbserver-only code, but then OTOH, some of the files under gdb/arch/ already have
conditional compilation with #ifdef GDBSERVER, unfortunately, so we're not ready to move them
somewhere where they're compiled once.

> 
> Another (more involved) option would be to see if these files could get
> moved to gdbsupport.

Yeah.

[PATCH 3/3] gdbsupport: move more things to gdbsupport.inc.h

[Simon Marchi]

Move some more of the things that should be seen everywhere by all
compilation units from common-defs.h to gdbsupport.inc.h.

After this change, to the best of my knowledge, common-defs.h, server.h
and defs.h are no longer special, they don't need to be included first
anymore.  A lot of source files don't need what is directly defined in
common-defs.h / server.h / defs.h , but rather use things in header
files included transitively.  There's no rush to do so, but for these
files, we'll be able to remove the inclusion of common-defs.h / server.h
/ defs.h and make them include what they actually use.

Ultimately, I think we could just get rid of these header files, since
they pretty much just server as big bags of includes.  Moving to more
fine-graned includes means less unnecessary includes, meaning less
unnecessary recompilation when some header file is modified.

The things moved to gdbsupport.inc.h are:

 - __STDC_CONSTANT_MACROS, __STDC_LIMIT_MACROS, __STDC_FORMAT_MACROS:
   according to the comment, they must be defined before including some
   standard headers.  Are these defines still useful though?

 - _FORTIFY_SOURCE: must come before any standard library include.

 - _WIN32_WINNT: must come before including the Windows API headers.

 - ATTRIBUTE_PRINTF, ATTRIBUTE_NONNULL: we override what ansidecl.h
   gives us.  So better define it in gdbsupport.inc.h, so that there is
   no chance of some source file including ansidecl.h without having the
   overrides.

 - HAVE_USEFUL_SBRK: this needs to be seen everywhere, in case one does
   `#ifdef HAVE_USEFUL_SBRK`.

 - Inclusion of poison.h, so that all code everywhere, uses our
   overrides of xfree & co.  This requires including liberty.h in
   poison.h, since it overrides some macros from it.

 - Since poison.h uses xfree and xfree uses some traits defined in
   poison.h, but gnulib also defines its own (non-templated) version of
   xfree, I had some strange error due to some non-compatible
   redefinitions.  All in all, it becomes simpler to move xfree to
   poison.h and get rid of gdb-xfree.h, so do that.

Change-Id: I21ad69e5f38f9fd7a3943d9f96d3782739d4b6df
---
 gdbsupport/common-defs.h    | 147 -----------------------------------
 gdbsupport/common-utils.cc  |   1 -
 gdbsupport/gdb-xfree.h      |  41 ----------
 gdbsupport/gdb_unique_ptr.h |   1 -
 gdbsupport/gdbsupport.inc.h | 149 ++++++++++++++++++++++++++++++++++++
 gdbsupport/poison.h         |  20 ++++-
 6 files changed, 167 insertions(+), 192 deletions(-)
 delete mode 100644 gdbsupport/gdb-xfree.h

diff --git a/gdbsupport/common-defs.h b/gdbsupport/common-defs.h
index e7eb814f3251..401e3c4ef099 100644
--- a/gdbsupport/common-defs.h
+++ b/gdbsupport/common-defs.h
@@ -20,60 +20,6 @@
 #ifndef COMMON_COMMON_DEFS_H
 #define COMMON_COMMON_DEFS_H
 
-/* From:
-    https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
-
-   "On some hosts that predate C++11, when using C++ one must define
-   __STDC_CONSTANT_MACROS to make visible the definitions of constant
-   macros such as INTMAX_C, and one must define __STDC_LIMIT_MACROS to
-   make visible the definitions of limit macros such as INTMAX_MAX.".
-
-   And:
-    https://www.gnu.org/software/gnulib/manual/html_node/inttypes_002eh.html
-
-   "On some hosts that predate C++11, when using C++ one must define
-   __STDC_FORMAT_MACROS to make visible the declarations of format
-   macros such as PRIdMAX."
-
-   Must do this before including any system header, since other system
-   headers may include stdint.h/inttypes.h.  */
-#define __STDC_CONSTANT_MACROS 1
-#define __STDC_LIMIT_MACROS 1
-#define __STDC_FORMAT_MACROS 1
-
-/* Some distros enable _FORTIFY_SOURCE by default, which on occasion
-   has caused build failures with -Wunused-result when a patch is
-   developed on a distro that does not enable _FORTIFY_SOURCE.  We
-   enable it here in order to try to catch these problems earlier;
-   plus this seems like a reasonable safety measure.  The check for
-   optimization is required because _FORTIFY_SOURCE only works when
-   optimization is enabled.  If _FORTIFY_SOURCE is already defined,
-   then we don't do anything.  Also, on MinGW, fortify requires
-   linking to -lssp, and to avoid the hassle of checking for
-   that and linking to it statically, we just don't define
-   _FORTIFY_SOURCE there.  */
-
-#if (!defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0 \
-     && !defined(__MINGW32__))
-#define _FORTIFY_SOURCE 2
-#endif
-
-/* We don't support Windows versions before XP, so we define
-   _WIN32_WINNT correspondingly to ensure the Windows API headers
-   expose the required symbols.
-
-   NOTE: this must be kept in sync with common.m4.  */
-#if defined (__MINGW32__) || defined (__CYGWIN__)
-# ifdef _WIN32_WINNT
-#  if _WIN32_WINNT < 0x0501
-#   undef _WIN32_WINNT
-#   define _WIN32_WINNT 0x0501
-#  endif
-# else
-#  define _WIN32_WINNT 0x0501
-# endif
-#endif	/* __MINGW32__ || __CYGWIN__ */
-
 #include <stdarg.h>
 #include <stdio.h>
 
@@ -93,89 +39,6 @@
 #include <alloca.h>
 #endif
 
-#include "ansidecl.h"
-/* This is defined by ansidecl.h, but we prefer gnulib's version.  On
-   MinGW, gnulib might enable __USE_MINGW_ANSI_STDIO, which may or not
-   require use of attribute gnu_printf instead of printf.  gnulib
-   checks that at configure time.  Since _GL_ATTRIBUTE_FORMAT_PRINTF_STANDARD
-   is compatible with ATTRIBUTE_PRINTF, simply use it.  */
-#undef ATTRIBUTE_PRINTF
-#define ATTRIBUTE_PRINTF _GL_ATTRIBUTE_FORMAT_PRINTF_STANDARD
-
-/* This is defined by ansidecl.h, but we disable the attribute.
-
-   Say a developer starts out with:
-   ...
-   extern void foo (void *ptr) __attribute__((nonnull (1)));
-   void foo (void *ptr) {}
-   ...
-   with the idea in mind to catch:
-   ...
-   foo (nullptr);
-   ...
-   at compile time with -Werror=nonnull, and then adds:
-   ...
-    void foo (void *ptr) {
-   +  gdb_assert (ptr != nullptr);
-    }
-   ...
-   to catch:
-   ...
-   foo (variable_with_nullptr_value);
-   ...
-   at runtime as well.
-
-   Said developer then verifies that the assert works (using -O0), and commits
-   the code.
-
-   Some other developer then checks out the code and accidentally writes some
-   variant of:
-   ...
-   foo (variable_with_nullptr_value);
-   ...
-   and builds with -O2, and ... the assert doesn't trigger, because it's
-   optimized away by gcc.
-
-   There's no suppported recipe to prevent the assertion from being optimized
-   away (other than: build with -O0, or remove the nonnull attribute).  Note
-   that -fno-delete-null-pointer-checks does not help.  A patch was submitted
-   to improve gcc documentation to point this out more clearly (
-   https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576218.html ).  The
-   patch also mentions a possible workaround that obfuscates the pointer
-   using:
-   ...
-    void foo (void *ptr) {
-   +  asm ("" : "+r"(ptr));
-      gdb_assert (ptr != nullptr);
-    }
-   ...
-   but that still requires the developer to manually add this in all cases
-   where that's necessary.
-
-   A warning was added to detect the situation: -Wnonnull-compare, which does
-   help in detecting those cases, but each new gcc release may indicate a new
-   batch of locations that needs fixing, which means we've added a maintenance
-   burden.
-
-   We could try to deal with the problem more proactively by introducing a
-   gdb_assert variant like:
-   ...
-   void gdb_assert_non_null (void *ptr) {
-      asm ("" : "+r"(ptr));
-      gdb_assert (ptr != nullptr);
-    }
-    void foo (void *ptr) {
-      gdb_assert_nonnull (ptr);
-    }
-   ...
-   and make it a coding style to use it everywhere, but again, maintenance
-   burden.
-
-   With all these things considered, for now we go with the solution with the
-   least maintenance burden: disable the attribute, such that we reliably deal
-   with it everywhere.  */
-#undef ATTRIBUTE_NONNULL
-#define ATTRIBUTE_NONNULL(m)
 
 #define ATTRIBUTE_UNUSED_RESULT __attribute__ ((__warn_unused_result__))
 #define ATTRIBUTE_USED __attribute__ ((__used__))
@@ -193,18 +56,8 @@
 #include "common-debug.h"
 #include "cleanups.h"
 #include "common-exceptions.h"
-#include "gdbsupport/poison.h"
 
 /* Pull in gdb::unique_xmalloc_ptr.  */
 #include "gdbsupport/gdb_unique_ptr.h"
 
-/* sbrk on macOS is not useful for our purposes, since sbrk(0) always
-   returns the same value.  brk/sbrk on macOS is just an emulation
-   that always returns a pointer to a 4MB section reserved for
-   that.  */
-
-#if defined (HAVE_SBRK) && !__APPLE__
-#define HAVE_USEFUL_SBRK 1
-#endif
-
 #endif /* COMMON_COMMON_DEFS_H */
diff --git a/gdbsupport/common-utils.cc b/gdbsupport/common-utils.cc
index 99b9cb8609bb..35a4c66f4546 100644
--- a/gdbsupport/common-utils.cc
+++ b/gdbsupport/common-utils.cc
@@ -21,7 +21,6 @@
 #include "common-utils.h"
 #include "host-defs.h"
 #include "gdbsupport/gdb-safe-ctype.h"
-#include "gdbsupport/gdb-xfree.h"
 
 void *
 xzalloc (size_t size)
diff --git a/gdbsupport/gdb-xfree.h b/gdbsupport/gdb-xfree.h
deleted file mode 100644
index 09c75395b62f..000000000000
--- a/gdbsupport/gdb-xfree.h
+++ /dev/null
@@ -1,41 +0,0 @@
-/* Copyright (C) 1986-2024 Free Software Foundation, Inc.
-
-   This file is part of GDB.
-
-   This program is free software; you can redistribute it and/or modify
-   it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; either version 3 of the License, or
-   (at your option) any later version.
-
-   This program is distributed in the hope that it will be useful,
-   but WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-   GNU General Public License for more details.
-
-   You should have received a copy of the GNU General Public License
-   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
-
-#ifndef GDBSUPPORT_GDB_XFREE_H
-#define GDBSUPPORT_GDB_XFREE_H
-
-#include "gdbsupport/poison.h"
-
-/* GDB uses this instead of 'free', it detects when it is called on an
-   invalid type.  */
-
-template <typename T>
-static void
-xfree (T *ptr)
-{
-  static_assert (IsFreeable<T>::value, "Trying to use xfree with a non-POD \
-data type.  Use operator delete instead.");
-
-  if (ptr != NULL)
-#ifdef GNULIB_NAMESPACE
-    GNULIB_NAMESPACE::free (ptr);	/* ARI: free */
-#else
-    free (ptr);				/* ARI: free */
-#endif
-}
-
-#endif /* GDBSUPPORT_GDB_XFREE_H */
diff --git a/gdbsupport/gdb_unique_ptr.h b/gdbsupport/gdb_unique_ptr.h
index 19b1581dab5c..3c2ec4098bed 100644
--- a/gdbsupport/gdb_unique_ptr.h
+++ b/gdbsupport/gdb_unique_ptr.h
@@ -22,7 +22,6 @@
 
 #include <memory>
 #include <string>
-#include "gdbsupport/gdb-xfree.h"
 
 namespace gdb
 {
diff --git a/gdbsupport/gdbsupport.inc.h b/gdbsupport/gdbsupport.inc.h
index ab0999579528..bca15460e87b 100644
--- a/gdbsupport/gdbsupport.inc.h
+++ b/gdbsupport/gdbsupport.inc.h
@@ -33,3 +33,152 @@
 #undef PACKAGE_STRING
 #undef PACKAGE_TARNAME
 #undef PACKAGE_VERSION
+
+/* From:
+    https://www.gnu.org/software/gnulib/manual/html_node/stdint_002eh.html
+
+   "On some hosts that predate C++11, when using C++ one must define
+   __STDC_CONSTANT_MACROS to make visible the definitions of constant
+   macros such as INTMAX_C, and one must define __STDC_LIMIT_MACROS to
+   make visible the definitions of limit macros such as INTMAX_MAX.".
+
+   And:
+    https://www.gnu.org/software/gnulib/manual/html_node/inttypes_002eh.html
+
+   "On some hosts that predate C++11, when using C++ one must define
+   __STDC_FORMAT_MACROS to make visible the declarations of format
+   macros such as PRIdMAX."
+
+   Must do this before including any system header, since other system
+   headers may include stdint.h/inttypes.h.  */
+#define __STDC_CONSTANT_MACROS 1
+#define __STDC_LIMIT_MACROS 1
+#define __STDC_FORMAT_MACROS 1
+
+/* Some distros enable _FORTIFY_SOURCE by default, which on occasion
+   has caused build failures with -Wunused-result when a patch is
+   developed on a distro that does not enable _FORTIFY_SOURCE.  We
+   enable it here in order to try to catch these problems earlier;
+   plus this seems like a reasonable safety measure.  The check for
+   optimization is required because _FORTIFY_SOURCE only works when
+   optimization is enabled.  If _FORTIFY_SOURCE is already defined,
+   then we don't do anything.  Also, on MinGW, fortify requires
+   linking to -lssp, and to avoid the hassle of checking for
+   that and linking to it statically, we just don't define
+   _FORTIFY_SOURCE there.  */
+
+#if (!defined _FORTIFY_SOURCE && defined __OPTIMIZE__ && __OPTIMIZE__ > 0 \
+     && !defined(__MINGW32__))
+#define _FORTIFY_SOURCE 2
+#endif
+
+/* We don't support Windows versions before XP, so we define
+   _WIN32_WINNT correspondingly to ensure the Windows API headers
+   expose the required symbols.
+
+   NOTE: this must be kept in sync with common.m4.  */
+#if defined (__MINGW32__) || defined (__CYGWIN__)
+# ifdef _WIN32_WINNT
+#  if _WIN32_WINNT < 0x0501
+#   undef _WIN32_WINNT
+#   define _WIN32_WINNT 0x0501
+#  endif
+# else
+#  define _WIN32_WINNT 0x0501
+# endif
+#endif	/* __MINGW32__ || __CYGWIN__ */
+
+#include "ansidecl.h"
+/* This is defined by ansidecl.h, but we prefer gnulib's version.  On
+   MinGW, gnulib might enable __USE_MINGW_ANSI_STDIO, which may or not
+   require use of attribute gnu_printf instead of printf.  gnulib
+   checks that at configure time.  Since _GL_ATTRIBUTE_FORMAT_PRINTF_STANDARD
+   is compatible with ATTRIBUTE_PRINTF, simply use it.  */
+#undef ATTRIBUTE_PRINTF
+#define ATTRIBUTE_PRINTF _GL_ATTRIBUTE_FORMAT_PRINTF_STANDARD
+
+/* This is defined by ansidecl.h, but we disable the attribute.
+
+   Say a developer starts out with:
+   ...
+   extern void foo (void *ptr) __attribute__((nonnull (1)));
+   void foo (void *ptr) {}
+   ...
+   with the idea in mind to catch:
+   ...
+   foo (nullptr);
+   ...
+   at compile time with -Werror=nonnull, and then adds:
+   ...
+    void foo (void *ptr) {
+   +  gdb_assert (ptr != nullptr);
+    }
+   ...
+   to catch:
+   ...
+   foo (variable_with_nullptr_value);
+   ...
+   at runtime as well.
+
+   Said developer then verifies that the assert works (using -O0), and commits
+   the code.
+
+   Some other developer then checks out the code and accidentally writes some
+   variant of:
+   ...
+   foo (variable_with_nullptr_value);
+   ...
+   and builds with -O2, and ... the assert doesn't trigger, because it's
+   optimized away by gcc.
+
+   There's no suppported recipe to prevent the assertion from being optimized
+   away (other than: build with -O0, or remove the nonnull attribute).  Note
+   that -fno-delete-null-pointer-checks does not help.  A patch was submitted
+   to improve gcc documentation to point this out more clearly (
+   https://gcc.gnu.org/pipermail/gcc-patches/2021-July/576218.html ).  The
+   patch also mentions a possible workaround that obfuscates the pointer
+   using:
+   ...
+    void foo (void *ptr) {
+   +  asm ("" : "+r"(ptr));
+      gdb_assert (ptr != nullptr);
+    }
+   ...
+   but that still requires the developer to manually add this in all cases
+   where that's necessary.
+
+   A warning was added to detect the situation: -Wnonnull-compare, which does
+   help in detecting those cases, but each new gcc release may indicate a new
+   batch of locations that needs fixing, which means we've added a maintenance
+   burden.
+
+   We could try to deal with the problem more proactively by introducing a
+   gdb_assert variant like:
+   ...
+   void gdb_assert_non_null (void *ptr) {
+      asm ("" : "+r"(ptr));
+      gdb_assert (ptr != nullptr);
+    }
+    void foo (void *ptr) {
+      gdb_assert_nonnull (ptr);
+    }
+   ...
+   and make it a coding style to use it everywhere, but again, maintenance
+   burden.
+
+   With all these things considered, for now we go with the solution with the
+   least maintenance burden: disable the attribute, such that we reliably deal
+   with it everywhere.  */
+#undef ATTRIBUTE_NONNULL
+#define ATTRIBUTE_NONNULL(m)
+
+#include "gdbsupport/poison.h"
+
+/* sbrk on macOS is not useful for our purposes, since sbrk(0) always
+   returns the same value.  brk/sbrk on macOS is just an emulation
+   that always returns a pointer to a 4MB section reserved for
+   that.  */
+
+#if defined (HAVE_SBRK) && !__APPLE__
+#define HAVE_USEFUL_SBRK 1
+#endif
diff --git a/gdbsupport/poison.h b/gdbsupport/poison.h
index 7b4f8e8a178d..cb1f474b5c5b 100644
--- a/gdbsupport/poison.h
+++ b/gdbsupport/poison.h
@@ -20,6 +20,7 @@
 #ifndef COMMON_POISON_H
 #define COMMON_POISON_H
 
+#include "libiberty.h"
 #include "traits.h"
 #include "obstack.h"
 
@@ -90,8 +91,23 @@ using IsMallocable = std::is_trivially_constructible<T>;
 template<typename T>
 using IsFreeable = gdb::Or<std::is_trivially_destructible<T>, std::is_void<T>>;
 
-template <typename T, typename = gdb::Requires<gdb::Not<IsFreeable<T>>>>
-void free (T *ptr) = delete;
+/* GDB uses this instead of 'free', it detects when it is called on an
+   invalid type.  */
+
+template <typename T>
+static void
+xfree (T *ptr)
+{
+  static_assert (IsFreeable<T>::value, "Trying to use xfree with a non-POD \
+data type.  Use operator delete instead.");
+
+  if (ptr != NULL)
+#ifdef GNULIB_NAMESPACE
+    GNULIB_NAMESPACE::free (ptr);	/* ARI: free */
+#else
+    free (ptr);				/* ARI: free */
+#endif
+}
 
 template<typename T>
 static T *
-- 
2.44.0