Summary: | gdb-7.12.1 for arm-rtems4.12 fails to build on FreeBSD 11.0 | ||
---|---|---|---|
Product: | gdb | Reporter: | Chris Johns <chrisj> |
Component: | corefiles | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | critical | CC: | jhb, pedro, qiyao |
Priority: | P2 | ||
Version: | 7.12.1 | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
Chris Johns
2017-02-28 21:15:22 UTC
Is your compiler clang? I have no problem building gdb with clang++-3.6 on Linux. (In reply to Yao Qi from comment #1) > Is your compiler clang? I have no problem building gdb with clang++-3.6 on > Linux. Yes, this is the default compiler for FreeBSD 11.0: $ /usr/bin/c++ --version FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) Target: x86_64-unknown-freebsd11.0 Thread model: posix InstalledDir: /usr/bin I was just looking into this on gdb's git HEAD branch and it seems gnulib's configure is using the default CPP which is a C compiler however GDB is not C++ and so the generated header file 'stddef.h' is not really suitable. The top of config.log for gnulib has 'CPP=' I suspect this needs to be the C++ compiler. I hacked gnulib/configure adding to the top something like: CPP="/usr/bin/c++ -E" and 'stddef.h' was correctly created. I could not figure out how to specify 'CPP=$CXX' to gnulib's configure. I did try setting CPP to CXX when calling the top level configure however building the binutils parts fails which is to be expected. The build did fail on further on with: In file included from ../../binutils-gdb/gdb/dwarf2read.c:72: ../../binutils-gdb/gdb/common/gdb_unlinker.h:35:35: error: '__nonnull__' attribute is invalid for the implicit this argument unlinker (const char *filename) ATTRIBUTE_NONNULL (1) ^ ~ ../../binutils-gdb/gdb/../include/ansidecl.h:169:48: note: expanded from macro 'ATTRIBUTE_NONNULL' # define ATTRIBUTE_NONNULL(m) __attribute__ ((__nonnull__ (m))) So it looks like there are other issues. FYI this issue is currently a blocker for RTEMS's 4.12 release. (In reply to Chris Johns from comment #2) > I was just looking into this on gdb's git HEAD branch and it seems gnulib's > configure is using the default CPP which is a C compiler however GDB is not > C++ Sorry I meant GDB *is* a C++ program. The issue is that the gnulib test checks for max_align_t using the C compiler but gdb is then compiled as C++. On FreeBSD 11.0, max_align_t is not defined in C, but is defined by libc++ when using C++. Thus, the configure tests gnulib runs don't find max_align_t, but when compiling with C++ the definition in libc++'s <stddef> triggers the error. I've fixed this in FreeBSD upstream by defining a proper max_align_t (the one in libc++ doesn't match the ABI of the one GCC uses) in both C and C++ in the base OS <stddef.h>. Additionally, in the port of gdb in the FreeBSD ports tree I use a local patch to disable the use of max_align_t from the gnulib header as a workaround for FreeBSD versions without max_align_t defined in C. The relevant commits to FreeBSD are: https://svnweb.freebsd.org/base?view=revision&revision=307756 https://svnweb.freebsd.org/base?view=revision&revision=309274 (both of which are merged to 11 and will be present in 11.1 when it is released). The hacky patch I use in the gdb port on FreeBSD is: https://svnweb.freebsd.org/ports/head/devel/gdb/files/patch-gdb-gnulib-import-stddef.in.h?view=co (The irony is that neither GDB nor binutils even use max_align_t.) I chose to fix the issue in this was as I considered the lack of max_align_t (which C11 requires) when compiling C in FreeBSD the bug. Thanks John, the patches resolve the issue for me. I will close this bug as invalid as it does not effect GDB. (In reply to Chris Johns from comment #2) > > The build did fail on further on with: > > In file included from ../../binutils-gdb/gdb/dwarf2read.c:72: > ../../binutils-gdb/gdb/common/gdb_unlinker.h:35:35: error: '__nonnull__' > attribute is invalid for the implicit this argument > unlinker (const char *filename) ATTRIBUTE_NONNULL (1) > ^ ~ > ../../binutils-gdb/gdb/../include/ansidecl.h:169:48: note: expanded from > macro 'ATTRIBUTE_NONNULL' > # define ATTRIBUTE_NONNULL(m) __attribute__ ((__nonnull__ (m))) > Yes, I saw this fail in my Linux build too. I've reported a GCC bug for the missing diagnostic: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79961 The master branch has been updated by Pedro Alves <palves@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=15c22686d0e33d87262bc9075296eeddd7d955f7 commit 15c22686d0e33d87262bc9075296eeddd7d955f7 Author: Pedro Alves <palves@redhat.com> Date: Wed Mar 8 15:52:16 2017 +0000 gdb: Fix ATTRIBUTE_NONNULL usage Should fix the build failure with Clang mentioned at <https://sourceware.org/bugzilla/show_bug.cgi?id=21206#c2>: In file included from ../../binutils-gdb/gdb/dwarf2read.c:72: ../../binutils-gdb/gdb/common/gdb_unlinker.h:35:35: error: '__nonnull__' attribute is invalid for the implicit this argument unlinker (const char *filename) ATTRIBUTE_NONNULL (1) ^ ~ ../../binutils-gdb/gdb/../include/ansidecl.h:169:48: note: expanded from macro 'ATTRIBUTE_NONNULL' # define ATTRIBUTE_NONNULL(m) __attribute__ ((__nonnull__ (m))) gdb/ChangeLog: 2017-03-08 Pedro Alves <palves@redhat.com> PR 21206 * common/gdb_unlinker.h (unlinker::unlinker): Attribute nonnull goes to argument 2, not 1. |