* GDB 13.1 and clang @ 2023-03-08 20:07 Chris Johns 2023-03-08 20:16 ` Andrew Pinski 2023-03-08 20:22 ` Simon Marchi 0 siblings, 2 replies; 12+ messages in thread From: Chris Johns @ 2023-03-08 20:07 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 13.1 and clang 2023-03-08 20:07 GDB 13.1 and clang Chris Johns @ 2023-03-08 20:16 ` Andrew Pinski 2023-03-08 20:22 ` Simon Marchi 1 sibling, 0 replies; 12+ messages in thread From: Andrew Pinski @ 2023-03-08 20:16 UTC (permalink / raw) To: Chris Johns; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 13.1 and clang 2023-03-08 20:07 GDB 13.1 and clang Chris Johns 2023-03-08 20:16 ` Andrew Pinski @ 2023-03-08 20:22 ` Simon Marchi 2023-03-08 21:22 ` Chris Johns 1 sibling, 1 reply; 12+ messages in thread From: Simon Marchi @ 2023-03-08 20:22 UTC (permalink / raw) To: Chris Johns, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 13.1 and clang 2023-03-08 20:22 ` Simon Marchi @ 2023-03-08 21:22 ` Chris Johns 2023-03-08 21:36 ` Simon Marchi 2023-03-08 22:53 ` John Baldwin 0 siblings, 2 replies; 12+ messages in thread From: Chris Johns @ 2023-03-08 21:22 UTC (permalink / raw) To: Simon Marchi, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 13.1 and clang 2023-03-08 21:22 ` Chris Johns @ 2023-03-08 21:36 ` Simon Marchi 2023-03-08 21:41 ` Chris Johns 2023-03-09 7:07 ` Eli Zaretskii 2023-03-08 22:53 ` John Baldwin 1 sibling, 2 replies; 12+ messages in thread From: Simon Marchi @ 2023-03-08 21:36 UTC (permalink / raw) To: Chris Johns, gdb > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 13.1 and clang 2023-03-08 21:36 ` Simon Marchi @ 2023-03-08 21:41 ` Chris Johns 2023-03-08 22:07 ` Joel Sherrill 2023-03-09 7:07 ` Eli Zaretskii 1 sibling, 1 reply; 12+ messages in thread From: Chris Johns @ 2023-03-08 21:41 UTC (permalink / raw) To: Simon Marchi, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 13.1 and clang 2023-03-08 21:41 ` Chris Johns @ 2023-03-08 22:07 ` Joel Sherrill 0 siblings, 0 replies; 12+ messages in thread From: Joel Sherrill @ 2023-03-08 22:07 UTC (permalink / raw) To: Chris Johns; +Cc: Simon Marchi, Eli Zaretskii via Gdb [-- 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 > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 13.1 and clang 2023-03-08 21:36 ` Simon Marchi 2023-03-08 21:41 ` Chris Johns @ 2023-03-09 7:07 ` Eli Zaretskii 1 sibling, 0 replies; 12+ messages in thread From: Eli Zaretskii @ 2023-03-09 7:07 UTC (permalink / raw) To: Simon Marchi; +Cc: chrisj, gdb > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 13.1 and clang 2023-03-08 21:22 ` Chris Johns 2023-03-08 21:36 ` Simon Marchi @ 2023-03-08 22:53 ` John Baldwin 2023-03-09 2:15 ` Simon Marchi 2023-03-09 2:41 ` Chris Johns 1 sibling, 2 replies; 12+ messages in thread From: John Baldwin @ 2023-03-08 22:53 UTC (permalink / raw) To: Chris Johns, Simon Marchi, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 13.1 and clang 2023-03-08 22:53 ` John Baldwin @ 2023-03-09 2:15 ` Simon Marchi 2023-03-09 3:20 ` Chris Johns 2023-03-09 2:41 ` Chris Johns 1 sibling, 1 reply; 12+ messages in thread From: Simon Marchi @ 2023-03-09 2:15 UTC (permalink / raw) To: John Baldwin, Chris Johns, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 13.1 and clang 2023-03-09 2:15 ` Simon Marchi @ 2023-03-09 3:20 ` Chris Johns 0 siblings, 0 replies; 12+ messages in thread From: Chris Johns @ 2023-03-09 3:20 UTC (permalink / raw) To: Simon Marchi, John Baldwin, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: GDB 13.1 and clang 2023-03-08 22:53 ` John Baldwin 2023-03-09 2:15 ` Simon Marchi @ 2023-03-09 2:41 ` Chris Johns 1 sibling, 0 replies; 12+ messages in thread From: Chris Johns @ 2023-03-09 2:41 UTC (permalink / raw) To: John Baldwin, Simon Marchi, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-03-09 7:07 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-03-08 20:07 GDB 13.1 and clang Chris Johns 2023-03-08 20:16 ` Andrew Pinski 2023-03-08 20:22 ` Simon Marchi 2023-03-08 21:22 ` Chris Johns 2023-03-08 21:36 ` Simon Marchi 2023-03-08 21:41 ` Chris Johns 2023-03-08 22:07 ` Joel Sherrill 2023-03-09 7:07 ` Eli Zaretskii 2023-03-08 22:53 ` John Baldwin 2023-03-09 2:15 ` Simon Marchi 2023-03-09 3:20 ` Chris Johns 2023-03-09 2:41 ` Chris Johns
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).