I've been trying to get gdb working on my mac, but alas. Here's the issue log.
| => gdb ./src admin
GNU gdb (GDB) 7.9
Copyright (C) 2015 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-darwin14.1.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 ./src...Reading symbols from /Users/home/CTCI-C/Chapter1/1.1/src.dSYM/Contents/Resources/DWARF/src...done.
done.
/Users/home/CTCI-C/Chapter1/1.1/admin: No such file or directory.
(gdb) b main
Breakpoint 1 at 0x100000e76: file src.c, line 17.
(gdb) c
The program is not being run.
(gdb)
Both gdb and gcc were installed using homebrew
| => which gdb
/usr/local/bin/gdb
which gcc
/usr/local/bin/gcc
When I do a r, this is what I get
(gdb) r
Starting program: /Users/home/CTCI-C/Chapter1/1.1/src
warning: Could not open OSO archive file "/BinaryCache/corecrypto/corecrypto-233.1.2~26/Symbols/BuiltProducts/libcorecrypto_static.a"
warning: `/BinaryCache/coreTLS/coreTLS-35.20.2~10/Objects/coretls.build/coretls.build/Objects-normal/x86_64/system_coretls_vers.o': can't open to read symbols: No such file or directory.
warning: Could not open OSO archive file "/BinaryCache/coreTLS/coreTLS-35.20.2~10/Symbols/BuiltProducts/libcoretls_ciphersuites.a"
warning: Could not open OSO archive file "/BinaryCache/coreTLS/coreTLS-35.20.2~10/Symbols/BuiltProducts/libcoretls_handshake.a"
warning: Could not open OSO archive file "/BinaryCache/coreTLS/coreTLS-35.20.2~10/Symbols/BuiltProducts/libcoretls_record.a"
warning: Could not open OSO archive file "/BinaryCache/coreTLS/coreTLS-35.20.2~10/Symbols/BuiltProducts/libcoretls_stream_parser.a"
Breakpoint 1, main (argc=1, argv=0x7fff5fbffac8) at src.c:17
17 char* str= argv[1];
(gdb)
What is possibly going wrong here. Any pointers.
Related
OS version: macOs Mojave 10.14.2
gdb: 8.2.1 (install with brew install gdb)
I have codesign successfully with
codesign --entitlements gdb-entitlement.xml -fs gdb-cert $(which gdb)
I have simple code like this:
int main(int argc, char *argv[])
{
std::cout << "hello, world" << std::endl;
return 0;
}
gdb hang then
zhifandeMacBook-Pro:cpp-quick-start zhifan$ g++ -g main.cpp
zhifandeMacBook-Pro:cpp-quick-start zhifan$ gdb ./a.out
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 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.2.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 ./a.out...Reading symbols from /Users/zhifan/github/cpp-quick-start/a.out.dSYM/Contents/Resources/DWARF/a.out...done.
done.
(gdb) start
Temporary breakpoint 1 at 0x100000f54: file main.cpp, line 5.
Starting program: /Users/zhifan/github/cpp-quick-start/a.out
[New Thread 0x1903 of process 11780]
[New Thread 0x1a03 of process 11780]
During startup program terminated with signal ?, Unknown signal.
(gdb) set startup-with-shell off
(gdb) start
Temporary breakpoint 2 at 0x100000f54: file main.cpp, line 5.
Starting program: /Users/zhifan/github/cpp-quick-start/a.out
[New Thread 0x2707 of process 11806]
My gdb hang here( [New Thread 0x2707 of process 11806]) all the time..
I can't use 8.0.1 since the issue unknown load command 0x32
what else can I do?
Ok, from my experience within the past two years of coding with a MacBook Pro. I have never been successful with getting gdb to work correctly. macOS uses the Xcode Developer tools for compiling. These tools include lldb which is very similar to gdb.
Here is a website that can help a bit to do this.
https://lldb.llvm.org/lldb-gdb.html
This is a map that directly shows gdb tools and lldb tools.
Hope this helps.
I got gdb working on Mojave today by:
a) getting the latest gdb source archive (at time of writing, ftp://sourceware.org/pub/gdb/snapshots/current/gdb-weekly-8.2.50.20190212.tar.xz) - amongst other things, it adds handling for recognizing executables on Mac.
b) build gdb. I got errors for variable shadowing in darwin-nat.c so I edited the file and rebuilt.
c) follow steps in https://forward-in-code.blogspot.com/2018/11/mojave-vs-gdb.html
Voila!
(source: GDB on Mac/Mojave: During startup program terminated with signal ?, Unknown signal)
I couldn't agree more with #Tanner Breckenridge. gdb just doesn't work on my mac, no matter what I tried. Just use something else.
lldb seems good, and for anyone who prefers a debugger with gui like me, I suggest using Visual Studio Code or Xcode to debug your C program instead.
I have a core dump file that has been generated by an erlang application and would like to analyze. This is my first time using gdb. I installed gdb but no luck running it with the executable and the core dump file.
I give gdb the executable and the core dump as
gdb erts-5.9.3/bin/beam.smp core
When I run that, I get,
GNU gdb (GDB) 7.9
Copyright (C) 2015 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.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 erts-5.9.3/bin/beam.smp...(no debugging symbols found)...done.
"/Users/sad/projects/core" is not a core dump: File format not recognized
Any help ? Thanks!
This GDB was configured as "x86_64-apple-darwin15.4.0".
"/Users/sad/projects/core" is not a core dump: File format not recognized
$ file core
/Users/sad/projects/core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), ...
Mac OS does not use ELF file format. We can safely assume that this core came from some other system, not the one you are trying to analyse it on.
It is still possible to analyse that core on the Mac OS system, but you need:
a cross-gdb (i.e. one that can run on Mac OS host, but can deal with ELF files for your target; it is likely that you'll have to build such GDB yourself) and
(unless you have a fully-static executable), you need complete set of shared libraries from the host on which the crash happened. See this answer.
In general, it is much easier to do the post-mortem analysis on the host where the crash happened.
I have gdb installed on my machine. Today I have compiled another version of gdb that is running fine. Now I want to debug this new gdb using my older gdb. Please guide me in this regard. How can I know that how gdb reads symbols from the provided executable, how it inserts break points, handles function calls and other things.
Thanks.
Think easily; when you want to debug some program, you probably compile it with -g or -ggdb and run gdb, don't you?
Download gdb source.
Compile it with -ggdb
./configure --prefix=<where-to-install>
make CFLAGS="-ggdb" CXXFLAGS="-ggdb"
make install
Debug it!
gdb <where-to-install>/bin/gdb
I've never tried it (and never thought it), but it may work. (And it looks very interesting; I'm about to try it!)
Um, I've just tested it in cygwin, and figure out the problem that the debugger gdb's output and the debuggee gdb's output are mixed; I solved it by using gdbserver to debug.
# On terminal 1..
$ gdbserver localhost:1234 gdb-gdb/prefix/bin/gdb
Process gdb-gdb/prefix/bin/gdb created; pid = 972
Listening on port 1234
Remote debugging from host 127.0.0.1
GNU gdb (GDB) 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 "i686-pc-mingw32".
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".
(gdb) q
Child exited with status 0
GDBserver exiting
and
# On terminal 2..
$ gdb gdb-gdb/prefix/bin/gdb
GNU gdb (GDB) 7.8
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 "i686-pc-cygwin".
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 gdb-gdb/prefix/bin/gdb...done.
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x7c93120f in ntdll!DbgBreakPoint ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) c
Continuing.
[Inferior 1 (Remote target) exited normally]
(gdb)
Once the first gdb starts running after taking the new gdb as an input file it will become paused after showing the info message. At this point you can put a break point on the function of new gdb which you want to execute.
e.g break insert_breakpoints // the function used to insert break points.
Now execute: run
This will start the execution of the new loaded gdb. Use file command to provide any executable HelloWorld.c comiled with -g option (for building debugging symbols) to the new gdb.
Now insert break point any where in the HelloWorld executable i.e
break main
This break command will call the insert_breakpoints function of gdb used for the insertion of breakpoints at which we have previously placed a break point.
Now you can use backtrace or other commands for examining the function calls and other stuff like that.
Hope that will solve your problem.
#ikh I think that gdb by default is compiled with debugging symbols because issuing :
file /path/to/compiled/gdb gives:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xd1c553318661f8b557f4c3640b02cee1ef512ac0, not stripped
Which means that it has debug info available in it.
Please correct me if I am wrong.
$ file app
app: Mach-O universal binary with 2 architectures
app (for architecture i386): Mach-O executable i386
app (for architecture x86_64): Mach-O 64-bit executable x86_64
$ gdb app
GNU gdb (GDB) 7.6
Copyright (C) 2013 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.0.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
"app": not in executable format: File format not recognized
$ file test
test: Mach-O 64-bit executable x86_64
$ gdb test
GNU gdb (GDB) 7.6
Copyright (C) 2013 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.0.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /Users/dmulder/test...Reading symbols from /Users/dmulder/test.dSYM/Contents/Resources/DWARF/test...done.
done.
Why would the 64bit binary succeed, but the 64+32 binary fail?
Unfortunately, the non-Apple version of GNU gdb is currently unable to debug universal (or 'fat') binaries (ones that contain both 32-bit and 64-bit executables).
One option is to use lipo to extract a single architecture and run gdb on that:
lipo -thin x86_64 -output app-x86_64 ./app
or
lipo -thin i386 -output app-i386 ./app
If you'd prefer to debug the combined executable, you could try using LLDB, or an Apple version of gdb.
As OP commented, using Apple's gdb will fix the problem.
Here are instructions to build Apple gdb 6.3.50.20050815-cvs from source on OS 10.9:
NOTE: You will need to install Xcode and set up a build environment. If you have Homebrew installed, run brew doctor to see if "Your system is ready to brew."
Download the gdb-1822 source tarball from: http://opensource.apple.com/tarballs/gdb/gdb-1822.tar.gz
Extract this into a temporary directory. Open a terminal and cd into gdb-1822/src.
Run the configure script:
./configure --prefix="$HOME/.local/stow/gdb-1822" --disable-debug --disable-dependency-tracking --with-system-readline
(The last three configure arguments are from the homebrew-dupes formula: https://github.com/Homebrew/homebrew-dupes/blob/master/gdb.rb )
Run make:
make
make install
Follow the instructions at https://sourceware.org/gdb/wiki/BuildingOnDarwin#Creating_a_certificate to create a gdb-cert code signing certificate.
cd into $HOME/.local/stow/gdb-1822/bin and sign the gdb executable:
codesign -s gdb-cert gdb
cd into $HOME/.local/stow and stow the gdb-1822 folder:
stow gdb-1822
Add $HOME/.local/bin to your PATH and either restart the terminal or clear Bash's cache to the location of gdb:
hash -d gdb
From this link: http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
-dH Produce a core dump whenever an error occurs.
So, I compiled a program with a syntax error and the core file was generated. How can that core file be used now? GDB can't be invoked since any executable has not been generated, yet.
[11:11:12 Wed Apr 27]
~/junk1 $ls
core hell.c
[11:11:15 Wed Apr 27]
~/junk1 $gcc -g hell.c -dH
hell.c: In function ‘main’:
hell.c:4: error: expected ‘;’ before ‘}’ token
gcc: Internal error: Aborted (program cc1)
Please submit a full bug report.
See <http://bugs.opensuse.org/> for instructions.
[11:11:36 Wed Apr 27]
~/junk1 $ls
core hell.c
[11:12:09 Wed Apr 27]
~/junk1 $gdb cc1 core
GNU gdb (GDB) SUSE (6.8.91.20090930-2.4)
Copyright (C) 2009 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-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
***cc1: No such file or directory.***
Missing separate debuginfo for the main executable file
Try: zypper install -C "debuginfo(build-id)=41f1efcceccfa5fa0b3476021c731c489547f86e"
Core was generated by `/usr/lib64/gcc/x86_64-suse-linux/4.4/cc1 -quiet hell.c -quiet -dumpbase hell.c'.
Program terminated with signal 6, Aborted.
#0 0x00007fb1b01654e5 in ?? ()
(gdb)
The GDB says: cc1: No such file or directory, in the above output.
How I am supposed to use that core file?
I think that switch is to help debug gcc, not your program. The page you link to starts like this:
3.9 Options for Debugging Your Program or GCC
GCC has various special options that are used for debugging either your program or GCC:
Emphasis mine.
The cc1 program is an internal part of GCC, it is probably somewhere under /usr/lib/ or /usr/libexec/.
gdb -c corefile should work. I haven't had to use the -dH option, so not sure how useful it is in helping with debugging.