Skip to content

Instantly share code, notes, and snippets.

@danisfermi
Created December 15, 2017 23:00
Show Gist options
  • Save danisfermi/17d6c0078a2fd4c6ee818c954d2de13c to your computer and use it in GitHub Desktop.
Save danisfermi/17d6c0078a2fd4c6ee818c954d2de13c to your computer and use it in GitHub Desktop.
Setup gdb on Mac OS Sierra/High Sierra

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
  1. Continue until "Specify a Location For"
  2. 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.
  3. Create certificate and close Certificate Assistant.
  4. Find the certificate in System keychain.
  5. Double click certificate.
  6. Expand Trust, set Code signing to Always Trust
  7. Restart taskgated in terminal: killall taskgated
  8. 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.
  9. Codesign gdb using your certificate: codesign -fs gdbc /usr/local/bin/gdb
  10. Shut down your mac and restart in recovery mode (hold down command-R until apple logo appears)
  11. Open terminal window
  12. Modify System Integrity Protection to allow debugging: csrutil enable --without debug
  13. Reboot your Mac. Debugging with gdb should now work as expected.
@shaleh
Copy link

shaleh commented Jun 8, 2018

!!I FOUND THE ANSWER TO THE -2,147,414,007 ERROR!!

Open Keychain Access.
In the upper left corner of the window is a lock that says "login" and another that says "System". Click the System lock. It will prompt for your password. Now the lock should appear unlocked.

You can now complete the steps above and save to System. Woot!

@puterd
Copy link

puterd commented Jun 17, 2018

Another thing to make sure of is that the debugger configuration in the worksession you have is linked to /usr/local/bin/gdb. You may have to set this every time but at least it works! :((

@zachgitt
Copy link

zachgitt commented Jul 2, 2018

After getting the -2147414007 errors, I followed this article which gave good step by step instructions to solve my problem.

https://medium.com/@royalstream/how-to-install-and-codesign-gdb-on-os-x-el-capitan-aab3d1172e95

In addition I needed to add "set startup-with-shell off" to my ~/.gdbinit file to avoid a message when running: "During startup program terminated with signal ?, unkown signal."

@hpuyang7942
Copy link

hpuyang7942 commented Aug 15, 2018

Hello there, first of all, thanks for your methods but there are still some problems with my macbook.
I am using OS X 10.13.6 and gdb version is 8.1.1
I have successfully finished the first nine steps you gave. But during the 10th, killall taskgated returned No matching processes belonging to you were found so I googled it and used sudo killall taskgated instead.
And under the recover mode, it returns the same as I input csrutil enable --without debug, both returns csrutil: requesting an unsupported configuration. This is likely to break in the future and leave your machine in an unknown state. csrutil: failed to modify system integrity configuration. This tool needs to be executed from the Recovery OS.
I tried use csrutil enable and returned successfully.
But the Eclipse still tells me gdb cannot be run due to unknow reason.
Would you please help me with that?

@kaituoxu
Copy link

@hpuyang7942 hi, did you fix this problem? I also met this problem.

@kaituoxu
Copy link

Follow the steps in this gist and notice related step:

  1. ps aux | grep taskgated find the PID, then sudu kill -9 PID
  2. codesign -fs gdbcert /usr/local/bin/gdb

@Nexus21
Copy link

Nexus21 commented Sep 19, 2018

Got to step 12 and was then stumped as it not clear what you mean:
"12. Codesign gdb using your certificate: codesign -fs gdbc /usr/local/bin/gdb"

Could you please clarify?
Where do I do that?

  • In the certificate? Could find nowhere to do this in the certificate, though there is a ´Code Signing´option, there is nowhere to enter text just a drop down with 3 options.

  • In terminal? Tried that and got:
    `...
    N2-MacBook-Pro:~ n2$ codesign -fs gdbc /usr/local/bin/gdb

    gdbc: no identity found
    ...`
    All help gratefully appreciated.

@logicalgroove
Copy link

@Nexus21 if you named the certificate in step 3 as gdbcert the command should be codesign -fs gdbcert /usr/local/bin/gdb

@theobouwman
Copy link

theobouwman commented Sep 26, 2018

\"/Users/theobouwman/Downloads/CppApplication_1/dist/Debug/GNU-MacOSX/cppapplication_1\": not in executable format: file format not recognized

Getting this error message when starting the debugger

@guoyilin42
Copy link

guoyilin42 commented Oct 4, 2018

\"/Users/theobouwman/Downloads/CppApplication_1/dist/Debug/GNU-MacOSX/cppapplication_1\": not in executable format: file format not recognized

Getting this error message when starting the debugger

have the same problem, I think maybe it is because of the GDB under the Mojave has some bugs

@deepio
Copy link

deepio commented Oct 6, 2018

\"/Users/theobouwman/Downloads/CppApplication_1/dist/Debug/GNU-MacOSX/cppapplication_1\": not in executable format: file format not recognized

Getting this error message when starting the debugger

have the same problem, I think maybe it is because of the GDB under the Mojave has some bugs

https://stackoverflow.com/questions/52529838/gdb-8-2-cant-recognized-executable-file-on-macos-mojave-10-14
I don't have a fix yet. You can use lldb, but that throws some errors too sometimes.

@reneeju
Copy link

reneeju commented Nov 4, 2018

follow the steps here : https://stackoverflow.com/questions/49222683/how-do-i-install-gdb-on-macos-10-13-3-high-sierra
downgraded gdb from 8.2 to 8.0.1 which resolved the issue below:

Break at address "0x10000419c" with no debug information available, or outside of program code.

@timotheecour
Copy link

how can I do step 15 (Modify System Integrity Protection to allow debugging: csrutil enable --without debug) from a macincloud instance ?

@timotheecour
Copy link

@danisfermi please update step 12:
Codesign gdb using your certificate: codesign -fs gdbc /usr/local/bin/gdb
to:
Codesign gdb using your certificate: codesign -fs gdbcert /usr/local/bin/gdb

@timotheecour
Copy link

timotheecour commented Nov 30, 2018

@benoitgoyet
Copy link

Hi,

I just make the update to correct the problem witj OS Mojave.
But i still have one problem : when starting debugging, there is an error :
[New Thread 0xc03 of process 36990]
[New Thread 0x1003 of process 36990]
During startup program terminated with signal ?, Unknown signal.

Do you have an idea of the reason?

THanks

@paulmadejong
Copy link

paulmadejong commented Dec 7, 2018

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

@duhd1993
Copy link

duhd1993 commented Jan 10, 2019

@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.

@jshardy
Copy link

jshardy commented Mar 4, 2019

@setup.db Thank you!!!

@rashenoy
Copy link

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

@humanitiesclinic
Copy link

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

@paulmadejong
Copy link

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.

@SyntevoAlex
Copy link

SyntevoAlex commented Jun 17, 2019

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.

@rustymagnet3000
Copy link

@abetancort
Copy link

@rustymagnet3000 Thanks for the heads up. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment