I am currently using a mid 2012 macbook Pro that is running macOS Mojave version 10.14.5. I am trying to use the GDB debugger for debugging C language code. I've already used Homebrew to install gdb on my computer, however it does not seem to work. Here is the output that I get from the terminal in VSCode:
steelwinds-MacBook-Pro:Chapter05 steelwind$ gdb ex2_dbg.out
GNU gdb (GDB) 9.1
Copyright (C) 2020 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-darwin18.7.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://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 <RET> for more, q to quit, c to continue without paging--<RET>
Type "apropos word" to search for commands related to "word"...
Reading symbols from ex2_dbg.out...
Reading symbols from
/Users/steelwind/HardWay/CandC++/CandC++/Chapter05/ex2_dbg.out.dSYM/Contents/Resources/
DWARF/ex2_dbg.out...
(gdb) run
Starting program: /Users/steelwind/HardWay/CandC++/CandC++/Chapter05/ex2_dbg.out
Unable to find Mach task port for process-id 7502: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
(gdb) q
steelwinds-MacBook-Pro:Chapter05 steelwind$
I'm not sure if I missed a step or if there is something that I should do instead of using Homebrew, but any advice is helpful.
The hint is this line: please check gdb is codesigned - see taskgated(8)
Because of one of Apple's security features, you will need to codesign GDB. Here's how to do that: "please check gdb is codesigned - see taskgated(8)" - How to get gdb installed with homebrew code signed?
I have installed gdb on my Mac (with Mac OS 10.9 / Mavericks) via homebrew and codesigned it successfully.
Before starting a debug session with gdb I compiled my C-files like in this example:
gcc -g test.c -o test
Afterwards I called gdb:
Users-MacBook-Pro:Test User$ gdb ./test
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 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-darwin13.4.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://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 ./test...Reading symbols from /Users/User/Test/test.dSYM/Contents/Resources/DWARF/test...done.
done.
Calling gdb commands like r or sta always results in the following error:
(gdb) r
Abort trap: 6
What is the problem? Any ideas how to fix it?
I'd suggest rebuilding gdb from the scratch. Instead of using some pre-built installations, you can always try to install it by yourself:
mkdir src
cd src
curl "http://ftp.gnu.org/gnu/gdb/gdb-8.0.tar.gz" -o gdb-8.0.tar.gz
tar zxf gdb-8.0.tar.gz
cd gdb-8.0
./configure --prefix=$HOME/opt/usr/local
make
make install
Remember to sign it before you can use it: https://gcc.gnu.org/onlinedocs/gcc-4.8.1/gnat_ugn_unw/Codesigning-the-Debugger.html
This way, you can easily debug your code. For details of installation, take a look here: Running GDB in macOS sierra
I am trying to debug a program which loads a shared library. I can debug the main program parts perfectly but in the shared library, I run into some problems.
gdb -p 70876
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 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-darwin15.5.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://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".
Attaching to process 70876
Reading symbols from /usr/local/pgsql/bin/postgres...done.
0x00007fff9496a2a2 in poll () from /usr/lib/system/libsystem_kernel.dylib
(gdb) b multi_ProcessUtility
Breakpoint 1 at 0xdaa9: multi_ProcessUtility. (2 locations)
(gdb) b multi_utility.c:129
Cannot access memory at address 0xdaa9
(gdb)
So, the problem is that, I can set a breakpoint with the method name itself and the program stops at the specified point. However, I cannot set the breakpoint with the filename and line number. (The specified filename and line number also addresses the same function)
When the program stops in the shared library function, running info source command result with No current source file. message
At the time I have attached to the process, the shared library is loaded and running.
I am on Mac OS X El Capitan, using GNU GCC 6 and GDB 7.11.1 from homebrew. I have compiled both the main program and the shared library with "-Og -ggdb -g3" flags.
I have solved my problem by downgrading to gdb 6.3.50.
Basically, I have installed gdb-apple from macports and it is based on gdb 6.3.50. I don't know whether it is related to gdb version or gdb-apple port has some tweaks that make it work.
I have a C program which a really complicated script is written to run it. I need to debug this program using gdb. I have tried to run the script and attach gdb to it's process, but then I'm not able to set breakpoints that I need:
$ gdb median.o 27944
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://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 median.o...done.
Attaching to program: median.o, process 27944
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007fc376e9cbfa in ?? ()
(gdb) break median.c:10
Cannot access memory at address 0x40059d
I also tried this:
$gdb -p 28303
GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1
Copyright (C) 2014 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://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".
Attaching to process 28303
Reading symbols from /bin/dash...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.19.so...done.
done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...Reading symbols from /usr/lib/debug//lib/x86_64-linux-gnu/ld-2.19.so...done.
done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
0x00007fe918e50bfa in wait4 () at ../sysdeps/unix/syscall-template.S:81
81 ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) break median.c:10
No source file named median.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (median.c:10) pending.
(gdb) continue
Continuing.
Please enter 3 numbers separated by spaces > 6 is the median
[Inferior 1 (process 28303) exited normally]
So it continues without stopping at the breakpoint. It is worth mentioning that if I call run median.o < input from gdb itself, it works.
How can I set breakpoints on a C program which is being run by a script?
This is a classic problem that people have with gdb. It's so common that you'd think it would have a handy name!
There are a few solutions to the problem, some time-tested and some relatively more experimental.
If the program to debug (in gdb lingo, "the inferior") is long-running -- for example, a GUI or a server of some kind -- then the simplest way is to just run the script, wait for the inferior to start, and then attach to it. You can attach using the PID, either with gdb -p PID or using attach PID at the gdb prompt.
If the program is short-lived, then another classic approach is to add a call to sleep early in the program's startup; say as the first line of main. Then, continue with the attach plan.
Those are the classic ways. But now let's talk about the more fun stuff.
gdb has a multi-inferior mode, where it can debug multiple processes at once. This mode, IME, is still a bit fragile, but I've had some success with it.
First you put gdb into the correct mode:
set detach-on-fork off
set non-stop off
set pagination off
(If you have an older gdb you will also need set target-async on).
Now you can debug the shell, something like:
$ gdb --args /bin/sh /path/to/my/script
(gdb) [... set the mode as above ...]
(gdb) break some_function_in_my_inferior
Now run should start the script, and automatically attach gdb to each child process that's created; eventually stopping at the breakpoint.
There's still one more way. A long time ago, there was a kernel patch to add "global breakpoints", plus a gdb patch to work with this feature. As far as I know, none of this was ever merged. But, I wrote a variant in my gdb helpers project.
There is a new command there called preattach. What it does is use SystemTap to watch for an exec of a specified program; then it pauses this program while gdb attaches to it.
This is my first question in StackOverflow since I joined some weeks ago and I wish someone could shed some light to this issue that drives me nuts! I've already searched thru the web, but I cannot find a successful solution to this problem.
I'm having some trouble with debugging with Netbeans 7.1 on Mac OSX 10.5.8 (Leopard) using GNU GDB. My problem is that I can't easily debug my own static or dynamic libraries from a test application because the debugger doesn't stop at breakpoints set in the source code of that libraries. However I've noticed that I can "step into" the library functions and, once I'm in them, breakpoints in those functions do fire!
My testbench consists on 2 simple projects: "mylib" (a C static library) and "mylib-test" (a C application). 'mylib' simply contains a header and a c file that define the function:
int sum(int a, int b) {
return a+b;
}
On the other hand, the mylib-test source simply uses that function:
int main(int argc, char** argv) {
printf("Result=%d\n", sum(111, 222));
return (EXIT_SUCCESS);
}
Both projects compile and execute successfully. For your convenience, below I put down the output of compiling/linking both projects:
Output of compiling mylib:
gcc -c -g -MMD -MP -MF build/Debug/GNU-MacOSX/m.o.d -o build/Debug/GNU-MacOSX/m.o m.c
mkdir -p dist/Debug/GNU-MacOSX
rm -f dist/Debug/GNU-MacOSX/libmylib.a
ar -rv dist/Debug/GNU-MacOSX/libmylib.a build/Debug/GNU-MacOSX/m.o
ar: creating archive dist/Debug/GNU-MacOSX/libmylib.a
a - build/Debug/GNU-MacOSX/m.o
ranlib dist/Debug/GNU-MacOSX/libmylib.a
Output of compiling mylib-test:
gcc -c -g -I../mylib -MMD -MP -MF build/Debug/GNU-MacOSX/main.o.d -o build/Debug/GNU-MacOSX/main.o main.c
mkdir -p dist/Debug/GNU-MacOSX
gcc -o dist/Debug/GNU-MacOSX/mylib-test build/Debug/GNU-MacOSX/main.o ../mylib/dist/Debug/GNU-MacOSX/libmylib.a
By examining the Debugger Console, I've noticed that breakpoints placed in the library's source code are marked as "PENDING" when I load the application on the debugger (see line starting by 12^done, field addr):
11-break-insert -f "/Users/claudi/dev/mylib-test/main.c:16"
12-break-insert -f "/Users/claudi/dev/mylib/m.c:5"
7^done,line="7",file="main.c",fullname="/Users/claudi/dev/mylib-test/main.c",time={wallclock="0.00065",user="0.00032",system="0.00029",start="1345544547.505531",end="1345544547.506184"}
(gdb)
13-break-insert -t main
&"cd /Users/claudi/dev/mylib-test\n"
8^done
(gdb)
9^done,time={wallclock="0.00002",user="0.00002",system="0.00000",start="1345544547.530991",end="1345544547.531013"}
(gdb)
&"set environment DYLD_LIBRARY_PATH=../mylib/dist/Debug/GNU-MacOSX\n"
10^done
(gdb)
11^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00001fb3",func="main",file="main.c",line="16",shlib="/Users/claudi/dev/mylib-test/dist/Debug/GNU-MacOSX/mylib-test",times="0"},time={wallclock="0.00058",user="0.00030",system="0.00029",start="1345544547.532421",end="1345544547.533003"}
(gdb)
12^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending="/Users/claudi/dev/mylib/m.c:5",times="0"},time={wallclock="0.00040",user="0.00018",system="0.00022",start="1345544547.533140",end="1345544547.533542"}
(gdb)
13^done,bkpt={number="3",type="breakpoint",disp="del",enabled="y",addr="0x00001fb3",func="main",file="main.c",line="16",shlib="/Users/claudi/dev/mylib-test/dist/Debug/GNU-MacOSX/mylib-test",times="0"},time={wallclock="0.00017",user="0.00016",system="0.00001",start="1345544547.552190",end="1345544547.552362"}
It seems that GDB is not loading the symbols of the library, yet it is actually linked statically (I mean, there are no dynamic libraries to load)!!
However, if I step into function sum from the main() function, and then place the breakpoint, then it is successfully resolved:
21-break-insert -f "/Users/claudi/dev/mylib/m.c:5"
21^done,bkpt={number="4",type="breakpoint",disp="keep",enabled="y",addr="0x00001fea",func="sum",file="m.c",line="5",shlib="/Users/claudi/dev/mylib-test/dist/Debug/GNU-MacOSX/mylib-test",times="0"},time={wallclock="0.00099",user="0.00039",system="0.00060",start="1345544947.877096",end="1345544947.878088"}
I hope I've given enough information... Does anybody have an idea of what's going on? Thank you in advance!
Further info:
GCC version: 686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5577)
GDB version: GNU gdb 6.3.50-20050815 (Apple version gdb-967)
Netbeans version: 7.1 (Build 201112071828)
////////////// EDIT //////////////////////////////////////////////////
So far I thought the problem was GDB, but today I've noticed it is not true: I've been able to debug the application directly using GDB from the command line, i.e., I could set breakpoints to my sum function and the debugger successfully stopped at them without the need to step into the function. So, I'm sure I'm having some issue with how NetBeans starts/initializes GDB. I've also noticed that NetBeans is trying to get features from GDB without success. From the debugger console:
~"GNU gdb 6.3.50-20050815 (Apple version gdb-967) (Tue Jul 14 02:11:58 UTC 2009)\n"
~"Copyright 2004 Free Software Foundation, Inc.\n"
~"GDB is free software, covered by the GNU General Public License, and you are\nwelcome
to change it and/or distribute copies of it under certain conditions.\nType \"show
copying\" to see the conditions.\nThere is absolutely no warranty for GDB. Type \"show
warranty\" for details.\n"
~"This GDB was configured as \"i386-apple-darwin\"."
~"\n"
(gdb)
2-list-features
3-gdb-set print repeat 0
4-gdb-set backtrace limit 1024
5-gdb-set print elements 0
6-file-exec-and-symbols "/Users/claudi/dev/mylib-test/dist/Debug/GNU-MacOSX/mylib-test"
2^error,msg="Undefined MI command: list-features"
I have no answer for this issue but I have some clues that could help finding solution.
I belive it's not NetBeans' fault. It's something with gdb. Probably it has to be compiled with some special configuration flag(s).
I was using gdb 7.4 (downloaded while ago with MinGW) with NetBeans 7.0-7.2 and Eclipse Juno on Windows 7 and everything was working as expected - gdb was stopping when entering breakpoints in my libraries (static or dynamic).
Lately I wanted to migrate to gdb compiled with Python support to get pretty-printing of complex STL structure in Eclipse. So I've downloaded latest gdb 7.5 sources and I've compiled it with "--with-python" flag:
./configure --with-python
make && make install
Pretty pretting works. Not even on Eclipse but with NetBeans as well (you only need to point to .gdbinit file in Project's Debug settings). The problem is my own compiled version of gdb has no ability to stop on breakpoints in my libraries (on NetBeans 7.2 and Eclipse Juno).
My conclusion is that gdb should be compiled with some flag(s) to get this ability. Or maybe it would be just sufficient to run it with some flag(s). I would also be grateful for help with this issue.
I'm attaching some possible useful informations:
Screenshots with correct stack trace on gdb 7.4
Screenshots with incorrect stack trace on gdb 7.5
Correct gdb:
C:\MinGW\bin>gdb --version
GNU gdb (GDB) 7.4
Copyright (C) 2012 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 "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
C:\MinGW\bin>gdbserver --version
GNU gdbserver (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
gdbserver is free software, covered by the GNU General Public License.
This gdbserver was configured as "i686-pc-mingw32"
Incorrect gdb:
C:\MinGW\bin>gdb --version
GNU gdb (GDB) 7.5
Copyright (C) 2012 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 "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
C:\MinGW\bin>gdbserver --version
GNU gdbserver (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
gdbserver is free software, covered by the GNU General Public License.
This gdbserver was configured as "i686-pc-mingw32"
I've checked at my work if absence of libexpat is causing gdb problem you described. And it seem that this is the case :) Try to compile and install expat first and then compile gdb from soruces.
Be sure to have:
checking for libexpat... yes
checking how to link with libexpat... <some_path>/libexpat.a
in your logs (somewhere after "make" command. not after "./configure").
To compile gdb I used gcc 4.6.2 from MinGW under Windows 7 and gdb-7.5 sources. I also added two additional configure flags but for sure they aren't necessery:
./configure --with-python --without-auto-load-safe-path