On macOS 11 (Big Sur), when GDB is built with an ELF target, for example --target=riscv64-unknown-elf, GDB builds successfully. At runtime, when an ELF file is loaded in GDB, the following message is raised: I'm sorry, Dave, I can't do that. Symbol format `elf32-littleriscv' unknown. It appears that despite the successful build, GDB does not include ELF support, as gdb/config.h contains `#undef HAVE_ELF` The root cause seems to be the gdb/configure script that fails to valide BFD ELF support, around line 16832 on GDB 10.1, although the same issue arise with the previous GDB 9.2 release. The generated conftest.c test fails as strncmp function is used, but <string.h> has not been included. I have not checked why the test file works on Linux hosts and not on macOS hosts. Anyway, adding <string.h> to acinclude.m4 fixes the trouble on macOS, such as with: --- a/gdb/acinclude.m4 2020-11-26 10:10:52.000000000 +0100 +++ b/gdb/acinclude.m4 2020-11-26 10:12:25.000000000 +0100 @@ -362,6 +362,7 @@ AC_CACHE_CHECK([$1], [$2], [AC_TRY_LINK( [#include <stdlib.h> + #include <string.h> #include "bfd.h" #include "$4" ], although I have no idea if this is the proper way to fix it. At least GDB keeps building in macOS 11, and the resulting gdb application is able to load ELF files. As a side note, is it an expected behaviour that building for an explicit ELF target completes successfully although ELF support cannot be included?
The linux compilers (gcc and clang) give a warning by default when a system header file is missing. The MacOS compiler is giving an error by default. It appears to be a configuration choice on the MacOS side. So some stuff that builds with a warning on linux will fail to build on macos. I ran into this same problem with riscv-gnu-toolchain recently. This looks like more failout from the CTF changes that added a call to strncmp to elf-bfd.h, so anything that includes elf-bfd.h now needs to also include string.h or it won't work on macos, and there is one place in configure.ac that is using elf-bfd.h but not including string.h. The proposed change looks reasonable to me. I'm not a gdb maintainer though.
I have a similar problem on Catalina and Big Sur. GDB failed with message: I'm sorry, Dave, I can't do that. Symbol format `elf64-x86-64' unknown. Some similar problem is also reported on stack overflow where I gave an answer what worked for me: https://stackoverflow.com/questions/65019289/gdb-fails-to-run-elf64-x86-64-format-on-gdbserver-rust-x64/65491753#65491753 However, building from source did not solve the problem for everyone so hopefully some GDB maintainer can have a look into it.
(In reply to Nick relvan from comment #2) > However, building from source did not solve the problem for everyone so > hopefully some GDB maintainer can have a look into it. No current GDB maintainer is known to have/use/develop on macOS, there hasn't been significant contribution to the macOS port for a long while. So if y'all want these bugs to get fixed, we will need some people who care about the platform to look into them. Otherwise, nothing will happen.
Ok, I understand. Thanks for letting us know. MacOS developers are likely to focus on LLDB, however I believe GDB is used as a debugger of choice for cross development, i.e. macOS host for embedded targets. Not a good news.
I came across this bug, adding "#include <string.h>" solves it for me.
Thank you, Emmanuel, for putting me on the right track. I ran into the same problem, building x86_64-elf-gdb on macOS 11.2.1. I fully agree with your problem analysis, but I'm not sure about your fix, which did not work for me. The specific compiler error I was getting concerned the call to strncmp() in bfd_section_is_ctf() in bfd/elf-bfd.h. Consequently, it seemed to me that the way to fix this would be to #include <string.h> in bfd/elf-bfd.h. This did fix the problem for me.
According to the BFD maintainer, it's expected that elf-bfd.h doesn't include the header files, see: https://sourceware.org/pipermail/gdb-patches/2020-November/173245.html I think this commit in master fixes the issue exactly how it's proposed in this bug, can you confirm? https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=b413232211bf
As requested by Simon, I tried rebuilding the master branch at commit b413232211bf7c7754095b017f27774d70646489. As expected, this does fix ELF support. Bug 26949 is therefore a duplicate. I was forced to compile with "-Wno-error=format-nonliteral -Wno-error=format-security", because of errors in files included by binutils-gdb/gdbsupport/common-defs.h that I had not previously encountered. (?? Did not investigate for now.) I don't know exactly what's involved, but if you need someone to test on macOS, I'd be happy to contribute.
(In reply to Philip Keller from comment #8) > As requested by Simon, I tried rebuilding the master branch at commit > b413232211bf7c7754095b017f27774d70646489. > > As expected, this does fix ELF support. Bug 26949 is therefore a duplicate. Thanks, I'll close it then. > > I was forced to compile with "-Wno-error=format-nonliteral > -Wno-error=format-security", because of errors in files included by > binutils-gdb/gdbsupport/common-defs.h that I had not previously encountered. > (?? Did not investigate for now.) > > I don't know exactly what's involved, but if you need someone to test on > macOS, I'd be happy to contribute. There isn't one particular thing that comes to mind, but last time I tried GDB on macOS (on someone else's computer) it just didn't seem to be in a good enough shape to be useful. Trying to run yielded cryptic errors, I figured GDB would need to be updated to keep up with newer macOS versions. What's your experience with it?
> last time I tried GDB on macOS [...] it just didn't seem to be in a good enough shape to be useful. [...] What's your experience with it? I do not use GDB for native debugging, I only use LLDB for this. However, GDB is *very* useful for cross debugging (in my case ARM & RISC-V targets); with these environments, I have not found any showstopper, although do not use advanced GDB features.
It's been many years since I really used gdb on Mac, always as a cross-debugger of course. Now I'm starting a new project, cross-compiling/debugging to embedded Linux (Yocto). I just got done setting up my development environment; gdb worked fine on Hello World & similar, but it did hang on a more complex test project. I haven't chased that one down yet; the project has a very complex object structure with multiple threads, console & network I/O, ... - many nooks & crannies that could fail. If gdb compiles, I don't see why it should be badly behaved on macOS. My experience is that (1) the clang compiler catches errors that gcc does not (and vice versa); and (2) macOS is missing some common libraries (e.g. internationalization). That second issue is usually easily remedied, for example with the MacPorts package manager. A native Mac development environment is worth something to me, so I intend to give it a good try, and I'd be happy to share what I find. However, I do have real work to do, so if it gets too much of a bother, I'll switch back to using a Linux VM development environment. Did that answer your question? Should I bother reporting back? If so, how?
Thanks, that's good feedback to know that you use GDB on macOS as a remote debugger for another platform. When I was talking about GDB being broken on macOS, I was thinking about the native debugging support. I expect GDB to work fine on macOS when used just as a client to connect to a remote target, as that only involves reading files and communicating using sockets. So nothing complicated, unlike native debugging. As far as i18n is concerned, I remembered having to use --disable-nls because gettext wouldn't build. But good for you if you managed to find how to get it to build with i18n :). We'd like GDB to build without warnings on all platforms, with both gcc and clang, so patches to fix build warnings on macOS would always be appreciated. People build on Linux with Clang regularly, so it usually builds fine, but Clang on macOS sometimes produces different warnings.
I think Emmanuel and I are very typical: no one in their right mind would use gdb to debug a native Mac app, but cross-debugging is very attractive for Mac fans. OK, so I'll spend some time chasing compilation errors/warnings. That should keep me busy: as far as I can tell, two problems have already crept into the master branch since the 10.1 release... Can I ask what the procedure is: is the goal to identify what patch introduced the problem, or is it enough to submit another patch that fixes it?
(In reply to Philip Keller from comment #14) > I think Emmanuel and I are very typical: no one in their right mind would > use gdb to debug a native Mac app, but cross-debugging is very attractive > for Mac fans. Heh :) > > OK, so I'll spend some time chasing compilation errors/warnings. That should > keep me busy: as far as I can tell, two problems have already crept into the > master branch since the 10.1 release... Thanks. If one is easier than the other, it's fine to start by fixing just one. > > Can I ask what the procedure is: is the goal to identify what patch > introduced the problem, or is it enough to submit another patch that fixes > it? The best would be to submit a patch that fixes the problem. Though in the GDB developers community, we really like well detailed commit messages. If it's possible to identify it, we like to mention which commit caused a regression in the commit message of the patch that fixes said regression. But it's not mandatory, especially in the case of simple build failures, up to you. Sometimes, it's not a commit in GDB that caused the regression, but a change in the platform. For example, maybe clang version X introduced a new diagnostic flag that introduces a new error/warning when building GDB. It's then useful to mention in the commit message that this warning was introduced a clang version X, since that explains why nobody saw it before. Here's the reference for submitting patches (the review happens on the gdb-patches mailing list): https://sourceware.org/gdb/wiki/ContributionChecklist If you have any questions about the workflow, please feel free to ask.
Thanks for the link to the Contribution Checklist. And I guess I'll learn about testing gdb, as well... A bit overwhelming to start, but I imagine I'll get the hang of it. In view of all this, I find the rate of commits astounding! I forgot to mention one driver for keeping cross-gdb working on macOS: the support for containerized builds, introduced in Eclipse CDT 10. As long as I have a macOS-hosted cross-gdb, it's now perfectly feasible to use Eclipse natively on macOS (in my case with a Yocto-generated toolchain). Nirvana for us Mac-geeks.