[Bug gdb/26949] New: ELF target support seems broken on macOS 11

[Bug gdb/26949] New: ELF target support seems broken on macOS 11

[eblot.ml at gmail dot com]

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

            Bug ID: 26949
           Summary: ELF target support seems broken on macOS 11
           Product: gdb
           Version: 10.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: eblot.ml at gmail dot com
  Target Milestone: ---

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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[eblot.ml at gmail dot com]

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

Emmanuel Blot <eblot.ml at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eblot.ml at gmail dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[wilson at gcc dot gnu.org]

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

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[big_deady2 at web dot de]

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

Nick relvan <big_deady2 at web dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |big_deady2 at web dot de

--- Comment #2 from Nick relvan <big_deady2 at web dot de> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #3 from Simon Marchi <simark at simark dot ca> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[eblot.ml at gmail dot com]

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

--- Comment #4 from Emmanuel Blot <eblot.ml at gmail dot com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[sify21 at 163 dot com]

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

FangYuan Si <sify21 at 163 dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sify21 at 163 dot com

--- Comment #5 from FangYuan Si <sify21 at 163 dot com> ---
I came across this bug, adding "#include <string.h>" solves it for me.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[keller at metrolab dot com]

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

Philip Keller <keller at metrolab dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |keller at metrolab dot com

--- Comment #6 from Philip Keller <keller at metrolab dot com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[simark at simark dot ca]

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

--- Comment #7 from Simon Marchi <simark at simark dot ca> ---
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[keller at metrolab dot com]

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

--- Comment #8 from Philip Keller <keller at metrolab dot com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[simark at simark dot ca]

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

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from Simon Marchi <simark at simark dot ca> ---
(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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[eblot.ml at gmail dot com]

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

--- Comment #10 from Emmanuel Blot <eblot.ml at gmail dot com> ---
> 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[keller at metrolab dot com]

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

--- Comment #11 from Philip Keller <keller at metrolab dot com> ---
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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[keller at metrolab dot com]

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

--- Comment #12 from Philip Keller <keller at metrolab dot com> ---
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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[simark at simark dot ca]

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

--- Comment #13 from Simon Marchi <simark at simark dot ca> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[keller at metrolab dot com]

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

--- Comment #14 from Philip Keller <keller at metrolab dot com> ---
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?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[simark at simark dot ca]

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

--- Comment #15 from Simon Marchi <simark at simark dot ca> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/26949] ELF target support seems broken on macOS 11

[keller at metrolab dot com]

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

--- Comment #16 from Philip Keller <keller at metrolab dot com> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.