Setup gdb on Mac OS Sierra/High Sierra

setupdb.md

Here are the steps to installing and setting up GDB on Mac OS Sierra/High Sierra. Run brew install gdb. On starting gdb, you will get the following error:

Unable to find Mach task port for process-id 2133: (os/kern) failure (0x5).
 (please check gdb is codesigned - see taskgated(8))

To fix this error, follow the following steps:

1. Open Keychain Access
2. In menu, open Keychain Access > Certificate Assistant > Create a Certificate
3. Give it a name (e.g. gdbcert)

• Identity type: Self Signed Root
• Certificate type: Code Signing
• Check: Let Me Override Defaults

4. Continue until "Specify a Location For"
5. Set Keychain location to System. If this yields the following error: Certificate Error: Unknown Error =-2,147,414,007 Set Location to Login, Unlock System by click on the lock at the top left corner and drag and drop the certificate gdbcert to the System Keychain.
6. Create certificate and close Certificate Assistant.
7. Find the certificate in System keychain.
8. Double click certificate.
9. Expand Trust, set Code signing to Always Trust
10. Restart taskgated in terminal: killall taskgated
11. Enable root account by following the steps given below: Open System Preferences. Go to User & Groups > Unlock. Login Options > "Join" (next to Network Account Server). Click "Open Directory Utility". Go up to Edit > Enable Root User.
12. Codesign gdb using your certificate: codesign -fs gdbc /usr/local/bin/gdb
13. Shut down your mac and restart in recovery mode (hold down command-R until apple logo appears)
14. Open terminal window
15. Modify System Integrity Protection to allow debugging: csrutil enable --without debug
16. Reboot your Mac. Debugging with gdb should now work as expected.

With GDB 8.2.1 (through Homebrew) and the steps above (without the Enable Root User) I still keep getting the code sign error in Mojave and GDB:

ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". Unable to find Mach task port for process-id 1510: (os/kern) failure (0x5).
 (please check gdb is  codesigned - see taskgated(8))

I also created a new certificate and tried again but no difference.

I then tried using these steps (using entitlements) https://stackoverflow.com/a/52994006
Now I no longer get the taskgated/codesigning error but the debugger just quits, similarly to benoitgoyet post above.

[New Thread 0xf03 of process 2188]
[New Thread 0x1003 of process 2188]
ERROR: Unable to start debugging. Unexpected GDB output from command "-exec-run". During startup program terminated with signal ?, Unknown signal.

Probably the same bug in 8.2 that is still present, see https://stackoverflow.com/questions/49001329/gdb-doesnt-work-on-macos-high-sierra-10-13-3

@paulmadejong

Did you manage to solve the problem? I think I got similar issues. There are posts talking about turning off SIP. This might work but I don't want to do that.

@setup.db Thank you!!!

@paulmadejong I am in the same boat as you. It will throw that error even after code-signing.

Hi, I was trying to install gdb on the Mac, and found your post. I followed your instructions, but now have an additional problem. Do you know why:
gdb can start, but it's showing:

start
Temporary breakpoint 1 at 0x100000f04
Starting program: /Users/user/Documents/codecompre_tooltest/a.out 
[New Thread 0x1703 of process 1645]
[New Thread 0x1903 of process 1645]
[New Thread 0x1a03 of process 1645]

[3]+  Stopped                 gdb a.out

I have SIP disabled apparently and with the HEAD version of gdb through brew it works for me with VSCode. However, sometimes in doesn't, in these cases, I just restart the application and then it works most of the time. No error in case it's not working though. So all in al, it works but not consistently.

Stacks are shown wrong for system libraries
Workaround: run debugged process with environment DYLD_SHARED_REGION=avoid.

Explanation:
This is due to dyld cache. When system libraries are loaded from cache, their segments are split in groups: first all __TEXT segments, then all __DATA segments, etc (this can be seen in vmmap --interleaved). However, GDB expects segments for a single library to follow each other (see GDB's code darwin_relocate_section_addresses). Apple's fork of GDB had support for dyld cache, see get_sectoffs_for_shared_cache_dylib, but Apple's GDB was discontinued in 2013 and replaced with LLDB. So the simplest workaround is to disable dyld cache for specific process.

This link more updated information:

https://timnash.co.uk/getting-gdb-to-semi-reliably-work-on-mojave-macos/

@rustymagnet3000 Thanks for the heads up. :-)