Monday, 13 February 2017

GDB vs macOS Sierra

We probably feel downhearted if we need to use the debugger to find out what's wrong with our Ada code.

Under those circumstances, we feel even more frustrated if the debugger doesn't work!

This is exactly what has happened with gdb and macOS Sierra.

For some time now, we've had to code-sign gdb. With Sierra 10.12.0, Apple changed System Integrity Protection in such a way that the default setting prevents gdb from starting a subprocess (i.e. starting the program to be debugged).

At Sierra 10.12.1, Apple reverted the System Integrity Protection change but altered the way that the debugger has to interact with the exec'd program.

There's discussion on the Sourceware Bugzilla (bug 20266), and on the AdaCore blog.

I've rebuilt GDB GPL 2016 to include the changes required.

  1. Download gdb-gpl-2016-sierra.tar.bz2.
  2. Change directory to the prefix of your GCC installation, e.g. /opt/gcc-6.1.0 or /opt/gnat-gpl-2016/bin; this gdb will work with either compiler.
  3. Unpack: e.g. tar jxvf ~/Downloads/gdb-gpl-2016-sierra.tar.bz2.
  4. Code-sign gdb.
  5. Edit ~/.gdbinit to include the line
    set startup-with-shell off

Now you should be good to go!

Edited 19.v.17: only need the csrutil hack on 10.12.0; new binary


  1. I seem to have it working for 10.12.4 (16E195), Darwin 16.5.0.

  2. However, when I type run I get, for example:
    Starting program: /OpenGL_Projects/Durian/hello/hello
    [New Thread 0x1403 of process 7800]
    warning: unhandled dyld version (15)

    This warning appears every time; however, gdb does continue to work.
    So far, I haven't figured out which dyld is the culprit.

  3. I get that too. Looking at GDB bug 20981 it seems this will only be a problem for debugging into dylibs.

    1. I now have gdb running under GNAT GPS.
      However, an additional problem that I can't solve is reported:
      Python Exception Installation error: gdb.execute_unwinders function is missing.

    2. Looks as though my upload didn’t include the necessary Python bits. Try this version: it needs to be unpacked at $prefix, e.g. /opt/gcc-6.1.0, on top of your existing GCC installation. Remember the codesigning bit.

    3. Thanks Simon,
      The Python warnings no longer appear and I can step through the program OK.