GDB 13.1 and clang

GDB 13.1 and clang

[Chris Johns]

Hi,

I have just tried to build the latest RTEMS tools and we now use gdb 13.1. I am
seeing a build failure on FreeBSD 13.1 of:

In file included from ../../gdb-13.1/gdb/xml-tdesc.c:23:
In file included from ../../gdb-13.1/gdb/target.h:42:
In file included from ../../gdb-13.1/gdb/infrun.h:21:
In file included from ../../gdb-13.1/gdb/gdbthread.h:26:
In file included from ../../gdb-13.1/gdb/breakpoint.h:38:
../../gdb-13.1/gdb/target/waitstatus.h:113:1: error: use of undeclared
identifier 'DIAGNOSTIC_ERROR_SWITCH'
DIAGNOSTIC_ERROR_SWITCH
^

I only have clang installed on the FreeBSD machine.

A quick review of include/diagnostics.h seems to show support for
DIAGNOSTIC_ERROR_SWITCH only in the gcc area?

Is this something I should raise a ticket for?

Thanks
Chris

Re: GDB 13.1 and clang

[Andrew Pinski]

On Wed, Mar 8, 2023 at 12:07 PM Chris Johns <chrisj@rtems.org> wrote:
>
> Hi,
>
> I have just tried to build the latest RTEMS tools and we now use gdb 13.1. I am
> seeing a build failure on FreeBSD 13.1 of:
>
> In file included from ../../gdb-13.1/gdb/xml-tdesc.c:23:
> In file included from ../../gdb-13.1/gdb/target.h:42:
> In file included from ../../gdb-13.1/gdb/infrun.h:21:
> In file included from ../../gdb-13.1/gdb/gdbthread.h:26:
> In file included from ../../gdb-13.1/gdb/breakpoint.h:38:
> ../../gdb-13.1/gdb/target/waitstatus.h:113:1: error: use of undeclared
> identifier 'DIAGNOSTIC_ERROR_SWITCH'
> DIAGNOSTIC_ERROR_SWITCH
> ^
>
> I only have clang installed on the FreeBSD machine.
>
> A quick review of include/diagnostics.h seems to show support for
> DIAGNOSTIC_ERROR_SWITCH only in the gcc area?

Huh? I looked into include/diagnostics.h in git and there is even:
#ifndef DIAGNOSTIC_ERROR_SWITCH
# define DIAGNOSTIC_ERROR_SWITCH
#endif

And before under `#if defined (__clang__) /* clang */`
# define DIAGNOSTIC_ERROR_SWITCH \
  DIAGNOSTIC_ERROR ("-Wswitch")

So I have no idea how it would be broken.
Unless somehow the wrong diagnostics.h is getting included. As far as
I can see include/diagnostics.h is the only one in git even.

Thanks,
Andrew Pinski

>
> Is this something I should raise a ticket for?
>
> Thanks
> Chris

Re: GDB 13.1 and clang

[Simon Marchi]

On 3/8/23 15:07, Chris Johns wrote:
> Hi,
> 
> I have just tried to build the latest RTEMS tools and we now use gdb 13.1. I am
> seeing a build failure on FreeBSD 13.1 of:
> 
> In file included from ../../gdb-13.1/gdb/xml-tdesc.c:23:
> In file included from ../../gdb-13.1/gdb/target.h:42:
> In file included from ../../gdb-13.1/gdb/infrun.h:21:
> In file included from ../../gdb-13.1/gdb/gdbthread.h:26:
> In file included from ../../gdb-13.1/gdb/breakpoint.h:38:
> ../../gdb-13.1/gdb/target/waitstatus.h:113:1: error: use of undeclared
> identifier 'DIAGNOSTIC_ERROR_SWITCH'
> DIAGNOSTIC_ERROR_SWITCH
> ^
> 
> I only have clang installed on the FreeBSD machine.
> 
> A quick review of include/diagnostics.h seems to show support for
> DIAGNOSTIC_ERROR_SWITCH only in the gcc area?

Hmm, I see it in the clang section:

# define DIAGNOSTIC_ERROR_SWITCH \
  DIAGNOSTIC_ERROR ("-Wswitch")

https://sourceware.org/cgit/binutils-gdb/tree/include/diagnostics.h?h=gdb-13.1-release&id=4f3e26ac6ee31f7bc4b04abd8bdb944e7f1fc5d2#n76

Unless there's a typo I don't see.

diagnostics.h is included at the top of waitstatus.h.  Is it possible
that another unrelated diagnostics.h gets included on FreeBSD?  You
could inspect the preprocessed file to see what the preprocessor
included for diagnostics.h.

Simon

Re: GDB 13.1 and clang

[Chris Johns]

On 9/3/2023 5:22 am, Simon Marchi wrote:
> On 3/8/23 15:07, Chris Johns wrote:
>> Hi,
>>
>> I have just tried to build the latest RTEMS tools and we now use gdb 13.1. I am
>> seeing a build failure on FreeBSD 13.1 of:
>>
>> In file included from ../../gdb-13.1/gdb/xml-tdesc.c:23:
>> In file included from ../../gdb-13.1/gdb/target.h:42:
>> In file included from ../../gdb-13.1/gdb/infrun.h:21:
>> In file included from ../../gdb-13.1/gdb/gdbthread.h:26:
>> In file included from ../../gdb-13.1/gdb/breakpoint.h:38:
>> ../../gdb-13.1/gdb/target/waitstatus.h:113:1: error: use of undeclared
>> identifier 'DIAGNOSTIC_ERROR_SWITCH'
>> DIAGNOSTIC_ERROR_SWITCH
>> ^
>>
>> I only have clang installed on the FreeBSD machine.
>>
>> A quick review of include/diagnostics.h seems to show support for
>> DIAGNOSTIC_ERROR_SWITCH only in the gcc area?
> 
> Hmm, I see it in the clang section:
> 
> # define DIAGNOSTIC_ERROR_SWITCH \
>   DIAGNOSTIC_ERROR ("-Wswitch")
> 

It seems I need to do a better review before posting :)

> https://sourceware.org/cgit/binutils-gdb/tree/include/diagnostics.h?h=gdb-13.1-release&id=4f3e26ac6ee31f7bc4b04abd8bdb944e7f1fc5d2#n76
> 
> Unless there's a typo I don't see.
> 
> diagnostics.h is included at the top of waitstatus.h.  Is it possible
> that another unrelated diagnostics.h gets included on FreeBSD?  You
> could inspect the preprocessed file to see what the preprocessor
> included for diagnostics.h.

There is another version installed here:

$ pkg which /usr/local/include/diagnostics.h
/usr/local/include/diagnostics.h was installed by package binutils-2.37_2,1

We have /usr/local/include early in the include list on FreeBSD to pick up some
of the required libraries installed as packages. I will check for a package
update or I revisit the build flags to see how it can be handled.

Thank you for the prompt and helpful responses.

Chris

Re: GDB 13.1 and clang

[Simon Marchi]

> There is another version installed here:
> 
> $ pkg which /usr/local/include/diagnostics.h
> /usr/local/include/diagnostics.h was installed by package binutils-2.37_2,1
> 
> We have /usr/local/include early in the include list on FreeBSD to pick up some
> of the required libraries installed as packages. I will check for a package
> update or I revisit the build flags to see how it can be handled.
Huh, diagnostics.h is an internal header file, I don't think binutils
packages should ship it.  I just looked up, and Ubuntu and Arch packages
ship it as well... sigh.

Simon

Re: GDB 13.1 and clang

[Chris Johns]

On 9/3/2023 6:36 am, Simon Marchi wrote:
>> There is another version installed here:
>>
>> $ pkg which /usr/local/include/diagnostics.h
>> /usr/local/include/diagnostics.h was installed by package binutils-2.37_2,1
>>
>> We have /usr/local/include early in the include list on FreeBSD to pick up some
>> of the required libraries installed as packages. I will check for a package
>> update or I revisit the build flags to see how it can be handled.
> Huh, diagnostics.h is an internal header file, I don't think binutils
> packages should ship it.  I just looked up, and Ubuntu and Arch packages
> ship it as well... sigh.

Ah, that is awkward as removing it from shipped packages is something we cannot
reach back and fix.

Rename diagnostics.h?

Chris

Re: GDB 13.1 and clang

[Joel Sherrill]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On Wed, Mar 8, 2023, 2:41 PM Chris Johns <chrisj@rtems.org> wrote:

> On 9/3/2023 6:36 am, Simon Marchi wrote:
> >> There is another version installed here:
> >>
> >> $ pkg which /usr/local/include/diagnostics.h
> >> /usr/local/include/diagnostics.h was installed by package
> binutils-2.37_2,1
> >>
> >> We have /usr/local/include early in the include list on FreeBSD to pick
> up some
> >> of the required libraries installed as packages. I will check for a
> package
> >> update or I revisit the build flags to see how it can be handled.
> > Huh, diagnostics.h is an internal header file, I don't think binutils
> > packages should ship it.  I just looked up, and Ubuntu and Arch packages
> > ship it as well... sigh.
>
> Ah, that is awkward as removing it from shipped packages is something we
> cannot
> reach back and fix.
>

And it could be in other packaging systems. Mays, Cyg

>
Admittedly not checking but is this header installed as part of make
install? I wouldn't think anyone would package something not installed.

>
> Rename diagnostics.h?
>

Works but rather awful.

Is it worth a check it's installed and there's a conflict?

--joel

>
> Chris
>

Re: GDB 13.1 and clang

[John Baldwin]

On 3/8/23 1:22 PM, Chris Johns wrote:
> On 9/3/2023 5:22 am, Simon Marchi wrote:
>> On 3/8/23 15:07, Chris Johns wrote:
>>> Hi,
>>>
>>> I have just tried to build the latest RTEMS tools and we now use gdb 13.1. I am
>>> seeing a build failure on FreeBSD 13.1 of:
>>>
>>> In file included from ../../gdb-13.1/gdb/xml-tdesc.c:23:
>>> In file included from ../../gdb-13.1/gdb/target.h:42:
>>> In file included from ../../gdb-13.1/gdb/infrun.h:21:
>>> In file included from ../../gdb-13.1/gdb/gdbthread.h:26:
>>> In file included from ../../gdb-13.1/gdb/breakpoint.h:38:
>>> ../../gdb-13.1/gdb/target/waitstatus.h:113:1: error: use of undeclared
>>> identifier 'DIAGNOSTIC_ERROR_SWITCH'
>>> DIAGNOSTIC_ERROR_SWITCH
>>> ^
>>>
>>> I only have clang installed on the FreeBSD machine.
>>>
>>> A quick review of include/diagnostics.h seems to show support for
>>> DIAGNOSTIC_ERROR_SWITCH only in the gcc area?
>>
>> Hmm, I see it in the clang section:
>>
>> # define DIAGNOSTIC_ERROR_SWITCH \
>>    DIAGNOSTIC_ERROR ("-Wswitch")
>>
> 
> It seems I need to do a better review before posting :)
> 
>> https://sourceware.org/cgit/binutils-gdb/tree/include/diagnostics.h?h=gdb-13.1-release&id=4f3e26ac6ee31f7bc4b04abd8bdb944e7f1fc5d2#n76
>>
>> Unless there's a typo I don't see.
>>
>> diagnostics.h is included at the top of waitstatus.h.  Is it possible
>> that another unrelated diagnostics.h gets included on FreeBSD?  You
>> could inspect the preprocessed file to see what the preprocessor
>> included for diagnostics.h.
> 
> There is another version installed here:
> 
> $ pkg which /usr/local/include/diagnostics.h
> /usr/local/include/diagnostics.h was installed by package binutils-2.37_2,1
> 
> We have /usr/local/include early in the include list on FreeBSD to pick up some
> of the required libraries installed as packages. I will check for a package
> update or I revisit the build flags to see how it can be handled.
> 
> Thank you for the prompt and helpful responses.

Yes, I manually delete all the headers installed by binutils into
/usr/local/include when building GDB from source locally to work
around this. :(  I'm not sure of the best fix for this.  I tracked
it down to the change to add zstd as ZSTD_CFLAGS is before BFD_CFLAGS
in INTERNAL_CFLAGS_BASE in Makefile.in in this commit:

commit 2cac01e3ffff74898c54fa5e6418817f5578adb6
Author: Fangrui Song <maskray@google.com>
Date:   Mon Sep 26 19:50:13 2022 -0700

     binutils, gdb: support zstd compressed debug sections
     
     PR29397 PR29563: Add new configure option --with-zstd which defaults to
     auto.  If pkgconfig/libzstd.pc is found, define HAVE_ZSTD and support
     zstd compressed debug sections for most tools.
     
     * bfd: for addr2line, objdump --dwarf, gdb, etc
     * gas: support --compress-debug-sections=zstd
     * ld: support ELFCOMPRESS_ZSTD input and --compress-debug-sections=zstd
     * objcopy: support ELFCOMPRESS_ZSTD input for
       --decompress-debug-sections and --compress-debug-sections=zstd
     * gdb: support ELFCOMPRESS_ZSTD input.  The bfd change references zstd
       symbols, so gdb has to link against -lzstd in this patch.
     
     If zstd is not supported, ELFCOMPRESS_ZSTD input triggers an error.  We
     can avoid HAVE_ZSTD if binutils-gdb imports zstd/ like zlib/, but this
     is too heavyweight, so don't do it for now.
     
     ```
     % ld/ld-new a.o
     ld/ld-new: a.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
     ...
     
     % ld/ld-new a.o --compress-debug-sections=zstd
     ld/ld-new: --compress-debug-sections=zstd: ld is not built with zstd support
     
     % binutils/objcopy --compress-debug-sections=zstd a.o b.o
     binutils/objcopy: --compress-debug-sections=zstd: binutils is not built with zstd support
     
     % binutils/objcopy b.o --decompress-debug-sections
     binutils/objcopy: zstd.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
     ...
     ```

I have not tried moving ZSTD_CFLAGS after BFD_CFLAGS, but if it worked I
think the right solution is to ensure all the "local" includes for things
in git come first before any includes that pull from the installed system.
I think this would mean moving READLINE_CFLAGS (for systems that use a
system readline), ZLIBINC, and ZSTD_CFLAGS after INCLUDE_CFLAGS.

I just tried this and it worked for me locally:

diff --git a/gdb/Makefile.in b/gdb/Makefile.in
index 6e39383eb93..40497541880 100644
--- a/gdb/Makefile.in
+++ b/gdb/Makefile.in
@@ -629,8 +629,8 @@ INTERNAL_CPPFLAGS = $(CPPFLAGS) @GUILE_CPPFLAGS@ @PYTHON_CPPFLAGS@ \
  # INTERNAL_CFLAGS is the aggregate of all other *CFLAGS macros.
  INTERNAL_CFLAGS_BASE = \
  	$(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
-	$(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) $(ZLIBINC) \
-	$(ZSTD_CFLAGS) $(BFD_CFLAGS) $(INCLUDE_CFLAGS) $(LIBDECNUMBER_CFLAGS) \
+	$(GDB_CFLAGS) $(OPCODES_CFLAGS) $(BFD_CFLAGS) $(INCLUDE_CFLAGS) \
+	$(READLINE_CFLAGS) $(ZLIBINC) $(ZSTD_CFLAGS) $(LIBDECNUMBER_CFLAGS) \
  	$(INTL_CFLAGS) $(INCGNU) $(INCSUPPORT) $(LIBBACKTRACE_INC) \
  	$(ENABLE_CFLAGS) $(INTERNAL_CPPFLAGS) $(SRCHIGH_CFLAGS) \
  	$(TOP_CFLAGS) $(PTHREAD_CFLAGS) $(DEBUGINFOD_CFLAGS) $(GMPINC) \

-- 
John Baldwin

Re: GDB 13.1 and clang

[Simon Marchi]

On 3/8/23 17:53, John Baldwin wrote:
> On 3/8/23 1:22 PM, Chris Johns wrote:
>> On 9/3/2023 5:22 am, Simon Marchi wrote:
>>> On 3/8/23 15:07, Chris Johns wrote:
>>>> Hi,
>>>>
>>>> I have just tried to build the latest RTEMS tools and we now use gdb 13.1. I am
>>>> seeing a build failure on FreeBSD 13.1 of:
>>>>
>>>> In file included from ../../gdb-13.1/gdb/xml-tdesc.c:23:
>>>> In file included from ../../gdb-13.1/gdb/target.h:42:
>>>> In file included from ../../gdb-13.1/gdb/infrun.h:21:
>>>> In file included from ../../gdb-13.1/gdb/gdbthread.h:26:
>>>> In file included from ../../gdb-13.1/gdb/breakpoint.h:38:
>>>> ../../gdb-13.1/gdb/target/waitstatus.h:113:1: error: use of undeclared
>>>> identifier 'DIAGNOSTIC_ERROR_SWITCH'
>>>> DIAGNOSTIC_ERROR_SWITCH
>>>> ^
>>>>
>>>> I only have clang installed on the FreeBSD machine.
>>>>
>>>> A quick review of include/diagnostics.h seems to show support for
>>>> DIAGNOSTIC_ERROR_SWITCH only in the gcc area?
>>>
>>> Hmm, I see it in the clang section:
>>>
>>> # define DIAGNOSTIC_ERROR_SWITCH \
>>>    DIAGNOSTIC_ERROR ("-Wswitch")
>>>
>>
>> It seems I need to do a better review before posting :)
>>
>>> https://sourceware.org/cgit/binutils-gdb/tree/include/diagnostics.h?h=gdb-13.1-release&id=4f3e26ac6ee31f7bc4b04abd8bdb944e7f1fc5d2#n76
>>>
>>> Unless there's a typo I don't see.
>>>
>>> diagnostics.h is included at the top of waitstatus.h.  Is it possible
>>> that another unrelated diagnostics.h gets included on FreeBSD?  You
>>> could inspect the preprocessed file to see what the preprocessor
>>> included for diagnostics.h.
>>
>> There is another version installed here:
>>
>> $ pkg which /usr/local/include/diagnostics.h
>> /usr/local/include/diagnostics.h was installed by package binutils-2.37_2,1
>>
>> We have /usr/local/include early in the include list on FreeBSD to pick up some
>> of the required libraries installed as packages. I will check for a package
>> update or I revisit the build flags to see how it can be handled.
>>
>> Thank you for the prompt and helpful responses.
> 
> Yes, I manually delete all the headers installed by binutils into
> /usr/local/include when building GDB from source locally to work
> around this. :(  I'm not sure of the best fix for this.  I tracked
> it down to the change to add zstd as ZSTD_CFLAGS is before BFD_CFLAGS
> in INTERNAL_CFLAGS_BASE in Makefile.in in this commit:
> 
> commit 2cac01e3ffff74898c54fa5e6418817f5578adb6
> Author: Fangrui Song <maskray@google.com>
> Date:   Mon Sep 26 19:50:13 2022 -0700
> 
>     binutils, gdb: support zstd compressed debug sections
>         PR29397 PR29563: Add new configure option --with-zstd which defaults to
>     auto.  If pkgconfig/libzstd.pc is found, define HAVE_ZSTD and support
>     zstd compressed debug sections for most tools.
>         * bfd: for addr2line, objdump --dwarf, gdb, etc
>     * gas: support --compress-debug-sections=zstd
>     * ld: support ELFCOMPRESS_ZSTD input and --compress-debug-sections=zstd
>     * objcopy: support ELFCOMPRESS_ZSTD input for
>       --decompress-debug-sections and --compress-debug-sections=zstd
>     * gdb: support ELFCOMPRESS_ZSTD input.  The bfd change references zstd
>       symbols, so gdb has to link against -lzstd in this patch.
>         If zstd is not supported, ELFCOMPRESS_ZSTD input triggers an error.  We
>     can avoid HAVE_ZSTD if binutils-gdb imports zstd/ like zlib/, but this
>     is too heavyweight, so don't do it for now.
>         ```
>     % ld/ld-new a.o
>     ld/ld-new: a.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
>     ...
>         % ld/ld-new a.o --compress-debug-sections=zstd
>     ld/ld-new: --compress-debug-sections=zstd: ld is not built with zstd support
>         % binutils/objcopy --compress-debug-sections=zstd a.o b.o
>     binutils/objcopy: --compress-debug-sections=zstd: binutils is not built with zstd support
>         % binutils/objcopy b.o --decompress-debug-sections
>     binutils/objcopy: zstd.o: section .debug_abbrev is compressed with zstd, but BFD is not built with zstd support
>     ...
>     ```
> 
> I have not tried moving ZSTD_CFLAGS after BFD_CFLAGS, but if it worked I
> think the right solution is to ensure all the "local" includes for things
> in git come first before any includes that pull from the installed system.
> I think this would mean moving READLINE_CFLAGS (for systems that use a
> system readline), ZLIBINC, and ZSTD_CFLAGS after INCLUDE_CFLAGS.
> 
> I just tried this and it worked for me locally:
> 
> diff --git a/gdb/Makefile.in b/gdb/Makefile.in
> index 6e39383eb93..40497541880 100644
> --- a/gdb/Makefile.in
> +++ b/gdb/Makefile.in
> @@ -629,8 +629,8 @@ INTERNAL_CPPFLAGS = $(CPPFLAGS) @GUILE_CPPFLAGS@ @PYTHON_CPPFLAGS@ \
>  # INTERNAL_CFLAGS is the aggregate of all other *CFLAGS macros.
>  INTERNAL_CFLAGS_BASE = \
>      $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
> -    $(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) $(ZLIBINC) \
> -    $(ZSTD_CFLAGS) $(BFD_CFLAGS) $(INCLUDE_CFLAGS) $(LIBDECNUMBER_CFLAGS) \
> +    $(GDB_CFLAGS) $(OPCODES_CFLAGS) $(BFD_CFLAGS) $(INCLUDE_CFLAGS) \
> +    $(READLINE_CFLAGS) $(ZLIBINC) $(ZSTD_CFLAGS) $(LIBDECNUMBER_CFLAGS) \
>      $(INTL_CFLAGS) $(INCGNU) $(INCSUPPORT) $(LIBBACKTRACE_INC) \
>      $(ENABLE_CFLAGS) $(INTERNAL_CPPFLAGS) $(SRCHIGH_CFLAGS) \
>      $(TOP_CFLAGS) $(PTHREAD_CFLAGS) $(DEBUGINFOD_CFLAGS) $(GMPINC) \

If it works, I'd be fine with that patch.  We'll need a PR number for
the patch to make it to the 13 branch though.

Simon

Re: GDB 13.1 and clang

[Chris Johns]

On 9/3/2023 7:53 am, John Baldwin wrote:
> On 3/8/23 1:22 PM, Chris Johns wrote:
>> On 9/3/2023 5:22 am, Simon Marchi wrote:
>>> On 3/8/23 15:07, Chris Johns wrote:
>>>> Hi,
>>>>
>>>> I have just tried to build the latest RTEMS tools and we now use gdb 13.1. I am
>>>> seeing a build failure on FreeBSD 13.1 of:
>>>>
>>>> In file included from ../../gdb-13.1/gdb/xml-tdesc.c:23:
>>>> In file included from ../../gdb-13.1/gdb/target.h:42:
>>>> In file included from ../../gdb-13.1/gdb/infrun.h:21:
>>>> In file included from ../../gdb-13.1/gdb/gdbthread.h:26:
>>>> In file included from ../../gdb-13.1/gdb/breakpoint.h:38:
>>>> ../../gdb-13.1/gdb/target/waitstatus.h:113:1: error: use of undeclared
>>>> identifier 'DIAGNOSTIC_ERROR_SWITCH'
>>>> DIAGNOSTIC_ERROR_SWITCH
>>>> ^
>>>>
>>>> I only have clang installed on the FreeBSD machine.
>>>>
>>>> A quick review of include/diagnostics.h seems to show support for
>>>> DIAGNOSTIC_ERROR_SWITCH only in the gcc area?
>>>
>>> Hmm, I see it in the clang section:
>>>
>>> # define DIAGNOSTIC_ERROR_SWITCH \
>>>    DIAGNOSTIC_ERROR ("-Wswitch")
>>>
>>
>> It seems I need to do a better review before posting :)
>>
>>> https://sourceware.org/cgit/binutils-gdb/tree/include/diagnostics.h?h=gdb-13.1-release&id=4f3e26ac6ee31f7bc4b04abd8bdb944e7f1fc5d2#n76
>>>
>>> Unless there's a typo I don't see.
>>>
>>> diagnostics.h is included at the top of waitstatus.h.  Is it possible
>>> that another unrelated diagnostics.h gets included on FreeBSD?  You
>>> could inspect the preprocessed file to see what the preprocessor
>>> included for diagnostics.h.
>>
>> There is another version installed here:
>>
>> $ pkg which /usr/local/include/diagnostics.h
>> /usr/local/include/diagnostics.h was installed by package binutils-2.37_2,1
>>
>> We have /usr/local/include early in the include list on FreeBSD to pick up some
>> of the required libraries installed as packages. I will check for a package
>> update or I revisit the build flags to see how it can be handled.
>>
>> Thank you for the prompt and helpful responses.
> 
> Yes, I manually delete all the headers installed by binutils into
> /usr/local/include when building GDB from source locally to work
> around this. :(  I'm not sure of the best fix for this.  

I am not sure why I have binutils installed on the box. I try to keep them clean
to make sure we have a base to test builds on. I suspect there is some skew in
the version binutils has and gdb now has.

> I tracked
> it down to the change to add zstd as ZSTD_CFLAGS is before BFD_CFLAGS
> in INTERNAL_CFLAGS_BASE in Makefile.in in this commit:
> 
> commit 2cac01e3ffff74898c54fa5e6418817f5578adb6
> Author: Fangrui Song <maskray@google.com>
> Date:   Mon Sep 26 19:50:13 2022 -0700
> 
>     binutils, gdb: support zstd compressed debug sections
>         PR29397 PR29563: Add new configure option --with-zstd which defaults to
>     auto.  If pkgconfig/libzstd.pc is found, define HAVE_ZSTD and support
>     zstd compressed debug sections for most tools.
>         * bfd: for addr2line, objdump --dwarf, gdb, etc
>     * gas: support --compress-debug-sections=zstd
>     * ld: support ELFCOMPRESS_ZSTD input and --compress-debug-sections=zstd
>     * objcopy: support ELFCOMPRESS_ZSTD input for
>       --decompress-debug-sections and --compress-debug-sections=zstd
>     * gdb: support ELFCOMPRESS_ZSTD input.  The bfd change references zstd
>       symbols, so gdb has to link against -lzstd in this patch.
>         If zstd is not supported, ELFCOMPRESS_ZSTD input triggers an error.  We
>     can avoid HAVE_ZSTD if binutils-gdb imports zstd/ like zlib/, but this
>     is too heavyweight, so don't do it for now.
>         ```
>     % ld/ld-new a.o
>     ld/ld-new: a.o: section .debug_abbrev is compressed with zstd, but BFD is
> not built with zstd support
>     ...
>         % ld/ld-new a.o --compress-debug-sections=zstd
>     ld/ld-new: --compress-debug-sections=zstd: ld is not built with zstd support
>         % binutils/objcopy --compress-debug-sections=zstd a.o b.o
>     binutils/objcopy: --compress-debug-sections=zstd: binutils is not built with
> zstd support
>         % binutils/objcopy b.o --decompress-debug-sections
>     binutils/objcopy: zstd.o: section .debug_abbrev is compressed with zstd, but
> BFD is not built with zstd support
>     ...
>     ```
> 
> I have not tried moving ZSTD_CFLAGS after BFD_CFLAGS, but if it worked I
> think the right solution is to ensure all the "local" includes for things
> in git come first before any includes that pull from the installed system.
> I think this would mean moving READLINE_CFLAGS (for systems that use a
> system readline), ZLIBINC, and ZSTD_CFLAGS after INCLUDE_CFLAGS.

Ah OK.

> I just tried this and it worked for me locally:
> 
> diff --git a/gdb/Makefile.in b/gdb/Makefile.in
> index 6e39383eb93..40497541880 100644
> --- a/gdb/Makefile.in
> +++ b/gdb/Makefile.in
> @@ -629,8 +629,8 @@ INTERNAL_CPPFLAGS = $(CPPFLAGS) @GUILE_CPPFLAGS@
> @PYTHON_CPPFLAGS@ \
>  # INTERNAL_CFLAGS is the aggregate of all other *CFLAGS macros.
>  INTERNAL_CFLAGS_BASE = \
>      $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
> -    $(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) $(ZLIBINC) \
> -    $(ZSTD_CFLAGS) $(BFD_CFLAGS) $(INCLUDE_CFLAGS) $(LIBDECNUMBER_CFLAGS) \
> +    $(GDB_CFLAGS) $(OPCODES_CFLAGS) $(BFD_CFLAGS) $(INCLUDE_CFLAGS) \
> +    $(READLINE_CFLAGS) $(ZLIBINC) $(ZSTD_CFLAGS) $(LIBDECNUMBER_CFLAGS) \
>      $(INTL_CFLAGS) $(INCGNU) $(INCSUPPORT) $(LIBBACKTRACE_INC) \
>      $(ENABLE_CFLAGS) $(INTERNAL_CPPFLAGS) $(SRCHIGH_CFLAGS) \
>      $(TOP_CFLAGS) $(PTHREAD_CFLAGS) $(DEBUGINFOD_CFLAGS) $(GMPINC) \

This worked, thanks. I will add it as a patch when building on FreeBSD and
remove it if this makes it into 13.2 or the development branch.

Again thanks
Chris

Re: GDB 13.1 and clang

[Chris Johns]

On 9/3/2023 11:15 am, Simon Marchi wrote:
>> On 3/8/23 17:53, John Baldwin wrote:
>> diff --git a/gdb/Makefile.in b/gdb/Makefile.in
>> index 6e39383eb93..40497541880 100644
>> --- a/gdb/Makefile.in
>> +++ b/gdb/Makefile.in
>> @@ -629,8 +629,8 @@ INTERNAL_CPPFLAGS = $(CPPFLAGS) @GUILE_CPPFLAGS@ @PYTHON_CPPFLAGS@ \
>>  # INTERNAL_CFLAGS is the aggregate of all other *CFLAGS macros.
>>  INTERNAL_CFLAGS_BASE = \
>>      $(GLOBAL_CFLAGS) $(PROFILE_CFLAGS) \
>> -    $(GDB_CFLAGS) $(OPCODES_CFLAGS) $(READLINE_CFLAGS) $(ZLIBINC) \
>> -    $(ZSTD_CFLAGS) $(BFD_CFLAGS) $(INCLUDE_CFLAGS) $(LIBDECNUMBER_CFLAGS) \
>> +    $(GDB_CFLAGS) $(OPCODES_CFLAGS) $(BFD_CFLAGS) $(INCLUDE_CFLAGS) \
>> +    $(READLINE_CFLAGS) $(ZLIBINC) $(ZSTD_CFLAGS) $(LIBDECNUMBER_CFLAGS) \
>>      $(INTL_CFLAGS) $(INCGNU) $(INCSUPPORT) $(LIBBACKTRACE_INC) \
>>      $(ENABLE_CFLAGS) $(INTERNAL_CPPFLAGS) $(SRCHIGH_CFLAGS) \
>>      $(TOP_CFLAGS) $(PTHREAD_CFLAGS) $(DEBUGINFOD_CFLAGS) $(GMPINC) \
> 
> If it works, I'd be fine with that patch.  We'll need a PR number for
> the patch to make it to the 13 branch though.

I have raised a ticket ..

https://sourceware.org/bugzilla/show_bug.cgi?id=30214

Chris

Re: GDB 13.1 and clang

[Eli Zaretskii]

> Date: Wed, 8 Mar 2023 16:36:45 -0500
> From: Simon Marchi via Gdb <gdb@sourceware.org>
> 
> > There is another version installed here:
> > 
> > $ pkg which /usr/local/include/diagnostics.h
> > /usr/local/include/diagnostics.h was installed by package binutils-2.37_2,1
> > 
> > We have /usr/local/include early in the include list on FreeBSD to pick up some
> > of the required libraries installed as packages. I will check for a package
> > update or I revisit the build flags to see how it can be handled.
> Huh, diagnostics.h is an internal header file, I don't think binutils
> packages should ship it.  I just looked up, and Ubuntu and Arch packages
> ship it as well... sigh.

diagnostics.h is included by bfd.h, which is installed by Binutils'
"make install", so I don't think they can avoid shipping
diagnostics.h.  They should maybe have a separate header file for
that, under some FOO_internal.h name or something, which could serve
for that purpose.  But this should be taken up with Binutils
maintainers, of course.