$ 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
Related
Problem
I'm trying to debug this Rust program using rust-gdb, but I can't seem to get GDB to work properly:
/home/a/tmp/foo(HEAD)
09/19/2021 09:57:23.114 AM> rust-gdb -q target/debug/foo
Reading symbols from target/debug/foo...
(gdb) b hello
Breakpoint 1 at 0x7a44: file src/main.rs, line 2.
(gdb) run
Starting program: /home/a/tmp/foo/target/debug/foo
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x7a44
(gdb)
I also tried setting the breakpoint using b src/main.rs:2 as well as running just gdb instead of the Rust wrapper rust-gdb both of which resulted in the same outcome. Am I doing this properly?
System Information
/home/a/tmp/foo(HEAD)
09/19/2021 09:07:48.200 AM> uname -a
Linux a 5.13.15_1 #1 SMP Fri Sep 10 16:52:33 UTC 2021 x86_64 GNU/Linux
/home/a/tmp/foo(HEAD)
09/19/2021 09:07:51.291 AM> rustc --version
rustc 1.55.0 (c8dfcfe04 2021-09-06)
/home/a/tmp/foo(HEAD)
09/19/2021 09:07:53.955 AM> gdb --version
GNU gdb (GDB) 10.2
Copyright (C) 2021 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.
I managed to get it working by uninstalling the installed gdb (which was obtained from the Nixpkgs repository) and replacing it with gdb from the Void Linux musl repository. I suspect the gdb from Nixpkgs was built with glibc and is incompatible with the compiled Rust program which was compiled to use musl instead. Usually, the Bedrock Linux userspace that I use allows me to use programs built with different C libraries together, but in this case I guess I needed GDB to be using the same C library as the thing it's trying to debug.
I am trying to cross-compile Linux for QEMU (RV64G ISA, lp64d ABI, Virt machine) using Buildroot. But apparently, GDB has been removed from buildroot version I'm using (2019.08), and is listed under the legacy list.
My objective is to be able to run RISC-V Linux application (in user-mode and softmmu) and with GDB debugging. I was able to build and run RISC-V apps using QEMU in both modes. But I didn't find a way to generate GDB like the other host utilities. Any ideas on how to do that?
A possible procedure for building a riscv64-linux-gnu-gdb from scratch would be :
PREFIX=$(pwd)/gdb-8.3.1-riscv64-linux-gnu
wget ftp://ftp.gnu.org/gnu/gdb/gdb-8.3.1.tar.xz
tar Jxf gdb-8.3.1.tar.xz
mkdir gdb
cd gdb
../gdb-8.3.1/configure --program-prefix=riscv64-linux-gnu- -with-tui --target=riscv64-linux-gnu --prefix=${PREFIX}
make all install
cd -
Build artifacts will located in $(pwd)/gdb-8.3.1-riscv64-linux-gnu:
ls -gG gdb-8.3.1-riscv64-linux-gnu/bin/riscv64-linux-gnu-gdb
-rwxr-xr-x 1 80395824 Sep 26 14:16 gdb-8.3.1-riscv64-linux-gnu/bin/riscv64-linux-gnu-gdb
gdb-8.3.1-riscv64-linux-gnu/bin/riscv64-linux-gnu-gdb --version
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 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.
If you don't want to build GDB with the TUI interface, remove --with-tui from the ./configure command.
I hope this helps.
gdb has certainly not been removed from Buildroot! However, back when the RISC-V support was added in Buildroot, the gdb support was not included, and therefore BR2_PACKAGE_HOST_GDB_ARCH_SUPPORTS depends on !BR2_riscv, which hides gdb when the RISC-V architecture is selected.
So one would need to see if there is an upstream version of gdb that supports RISC-V, and if there is, remove the !BR2_riscv dependency, and add the appropriate dependencies to prevent the user from selecting older gdb versions that don't have RISC-V support.
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.
How to install gdb on OSX 10.9?
I try to use macports:
port install gdb
Password:
...
---> Updating database of binaries: 100.0%
---> Scanning binaries for linking errors: 100.0%
---> No broken files found.
But I don't have gdb executable:
$ which gdb
$
I found out that macports gdb on mac is called ggdb. So I make a link:
sudo ln -s /opt/local/bin/ggdb /opt/local/bin/gdb
$ gdb --args ./prog -time
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 /prog...done.
(gdb) r
Starting program: /prog -time
Unable to find Mach task port for process-id 65740: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
(gdb)
So how to install gdb correctly on OSX 10.9?
P.S. Related questions, which doesn't help:
How to get a "codesigned" gdb on OSX?
"please check gdb is codesigned - see taskgated(8)" - How to get gdb installed with homebrew code signed?
I made it this way (described here):
sudo nano /System/Library/LaunchDaemons/com.apple.taskgated.plist
change option string from -s to -sp at line 22, col 27.
reboot the computer.
Use gdb
I have the following versions of Cygwin, yasm, gcc, and gdb:
CYGWIN_NT-5.1 Thorondor 1.7.7(0.230/5/3) 2010-08-31 09:58 i686 Cygwin
yasm 1.1.0.2352
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
I've compiled vp8 using the following commands:
$ ./configure --enable-debug
$ make
However when I try to debug using GDB, I get the following error:
$ gdb simple_decoder.exe
GNU gdb 6.8.0.20080328-cvs (cygwin-special)
Copyright (C) 2008 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"...
Dwarf Error: bad offset (0x4c4000) in compilation unit header (offset
0x0 + 6) [in module /cygdrive/
c/work/vp8/csim/build/simple_decoder.exe]
(gdb) q
Can someone help me out with this?
Thanks,
Arjun
Your compiler and binutils are too old. This was solved circa 2000, the fault comes from the linker (see http://gcc.gnu.org/ml/gcc-bugs/2000-06/msg00768.html)