gdb on macOS Ventura (M2) fails

[juananpe]

Hi, @simonjwright,

First of all, thank you for distributing the GCC binary tools for macOS and for documenting everything on your blog.

I'd like to continue this thread here. Using the comments section on Stack Overflow for extended discussion is quite cumbersome due to character limitations. If you'd rather discuss this elsewhere, please let me know.

I'm aware that PR24069 is a bug opened in 2019 for Intel CPUs, but it seems to affect Apple silicon laptops as well. At least, when I used your GDB build (after code-signing the binary and noting that this GDB is an x86_64 binary running under Rosetta on my M2), I encountered this bug trying to debug a trivial hello_world Ada program:

/opt/gcc-13.1.0/bin $ ./gdb /opt/adatutorial/.objs/hello_world
GNU gdb (GDB) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin21".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/adatutorial/.objs/hello_world...
(gdb) break main
Breakpoint 1 at 0x10000132f: file b__hello_world.adb, line 215.
(gdb) run
Starting program: /opt/adatutorial/.objs/hello_world
[New Thread 0x2e03 of process 2885]
[New Thread 0x3c03 of process 2885]
During startup program terminated with signal SIGTRAP, Trace/breakpoint trap.

A comment in that bug's thread in SO suggests PR24069 might be responsible. Honestly, I can't confirm if that's the root cause, but it appears likely.

I'm still uncertain if it's currently even possible to use any debugger (be it x86_64 GDB, aarch64 GDB or LLDB) to debug Ada programs on Apple silicon. From my tests, it seems impossible at the moment.

Any comments will be very much appreciated.

[simonjwright]

(gdb) run
Starting program: /opt/adatutorial/.objs/hello_world
[New Thread 0x2e03 of process 2885]
[New Thread 0x3c03 of process 2885]
During startup program terminated with signal SIGTRAP, Trace/breakpoint trap.

I don’t even get this! The program dies, but the gdb process just hangs, so I have to kill -9 from another terminal.

A fun day. First, my gdb-cert no longer worked:

$ sudo codesign --force --sign gdb-cert --entitlements ~/Dropbox/Public/gdb/gdb.xml /opt/gcc-14-20230514/bin/gdb
Password:
error: The specified item could not be found in the keychain.

so I had to make a new one. Then, I tried building GDB 13.2 on M1 using arch -x86_64 /bin/bash to get an Intel executable; I must have had finger trouble, because the result didn’t recognise mach-o x86_64 binary. Tried the build on Intel; can’t find libintl.h; it was in /usr/local/include (via brew install gettext) but not found.

Shouldn’t be this hard!

[juananpe]

Hi @simonjwright . I managed to build my own copy of gdb 13.2 from source using this incantation:

$ cd /tmp/gdb-13.2
$ GNATBIND=gnatbind GNATMAKE=gnatmake AR=ar arch -x86_64 ./configure --host=x86_64-apple-darwin22 --without-guile \
    --without-python \
    --disable-werror \
 --without-zstd

$ make -w all -j3

Then code signed it:

$ sudo codesign --force --sign gdb-cert --entitlements ./gdb.xml ./gdb/gdb

And finally tried to debug my hello_world binary (built for x86_64-darwin) :

$  ./gdb/gdb /opt/adatutorial/.objs/hello_world
GNU gdb (GDB) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin22".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /opt/adatutorial/.objs/hello_world...
(gdb) break main
Breakpoint 1 at 0x10000132f: file b__hello_world.adb, line 215.
(gdb) run
Starting program: /opt/adatutorial/.objs/hello_world
[New Thread 0x2403 of process 51642]
[New Thread 0x2a03 of process 51642]
During startup program terminated with signal SIGTRAP, Trace/breakpoint trap.

Same error ¯\(ツ)/¯

So, yeah, it really seems that it is impossible to debug a binary in Apple silicon using GDB. And due to the lack of Ada support in LLDB, AFAIK it is really impossible to debug an Ada binary in Apple silicon at all.

Interesting note: according to this file in AdaCore repo, it seems to me that GNAT Studio has had (has?) integrated LLDB debugger support, but when trying to enable it in the preferences, there is no option for LLDB (see attached image)

[juananpe]

Update: following these notes I built LLDB with "some" Ada support (usable from CLI)

Now I want to use it in VS Code, but I hit another issue.

[simonjwright]

This seems a great deal better than nothing!

catch exception (my most frequent use) might be trickier -- I suspect gdb/ada looks for calls to the GNAT exception raising mechanism (g-excdeb ?)

[juananpe]

Good news! Building LLDB against the 16.x branch of a rust-enabled LLDB version did the trick! Now I can debug Ada programs in VSCode in an Apple silicon (M2) with the CodeLLDB plugin :)

[simonjwright]

I build lldb using your patch (pretend that Ada can be treated like C++); worked fine for integer, boolean, enum but didn’t like a constrained type:

   type Constr is range 10 .. 100;
   C : Constr := 42;

resulting in

(lldb) v
error: try_lldb.o [0x0000000000000135]: unhandled type tag DW_TAG_subrange_type (DW_TAG_subrange_type), please file a bug and attach the file at the start of this error message
...
Error: 'Unable to determine byte size.'

so I think we’re doomed to do this the hard way! (i.e. by starting to implement an Ada TypeSystem).