GDB `run` command fails with "Cannot insert breakpoint 1." - debugging

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.

Related

Setting Breakpoints on ARM Thumb Instructions in GDB

I'm practicing reversing a stripped arm binary (that I wrote) and found that when I set a breakpoint at say 0x010451, and run the program, gdb spins forever until I hit ctrl+c. When I do, the current pc is at the address, but I can't continue the program.
When I set the breakpoint to 0x010450, gdb hits the breakpoint fine, but the instructions are being decoded as non-thumb instructions.
Is this expected? A bug? I will try to upload examples later today.
Version info (under qemu usermode emulation):
debian#debian-arm:~/lab$ gdb --version
GNU gdb (Debian 8.2.1-2+b3) 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.
debian#debian-arm:~/lab$ uname -a
Linux debian-arm 4.19.0-10-armmp-lpae #1 SMP Debian 4.19.132-1 (2020-07-24) armv7l GNU/Linux

Generating RISC-V Linux GDB using Buildroot

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.

How to debug gdb with itself

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.

GCC debugging option -dH

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.

problem compiling vp8 for debugging on Cygwin

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)

Resources