I am trying to use gdbserver...
I have an application with binary path /user/bin/foo running with pid 19767.
Started the gdbserver on remote:
gdbserver --remote-debug --multi 0:12347
Started gdb on client and connected it to remove server
target extended-remote 192.168.1.84:12347
Attached gdb on pid
attach 19767
It shows:
warning: Could not load vsyscall page because no executable was specified
try using the "file" command first.
0x00007f207550043c in ?? ()
Also, current thread information it is showing is incorrect. Like info threads shows 1 thread , but my app has 10 threads-
(gdb) info threads
* 1 Thread 19767.19767 0x00007f207550043c in ?? ()
How can I ask gdb to load symbol from remote file /user/bin/foo? How to make it show correct info?
How can I ask gdb to load symbol from remote file /user/bin/foo
You can't. Copy remote /usr/bin/foo locally (or mount the filesystem it's on), and then invoke gdb like this: gdb /path/to/copy/of/foo, or just use the file command.
As of gdb 7.10, you can use
set sysroot target:
to make gdb retrieve files from the remote filesystem. See https://sourceware.org/gdb/onlinedocs/gdb/Files.html#Files
Related
The following workflow worked for me at one point, and then it suddenly stopped working. I'd like to figure out why and get it to work again.
on the host, build binary for target system with debug information
send the stripped version of the binary to the target system
on the target, run the binary with gdbserver :6006 mybinary args...
on the host, run gdb-multiarch mybinary. This is the unstripped version. It shows that it loaded symbols from the local binary.
At the gdb prompt, run target remote <ip_of_target>:6006
Then, if I say b main, it inserts a breakpoint at an unrelocated address like 0x621730, which is the offset of the main function in the local binary, whereas it should be added on top of the VM address the remote binary is loaded at (0x5555555000 in this case.) Obviously the unrelocated address doesn't work.
So step 6 was working at one point. I don't know what I'm doing now differently to make the relocation no longer work. Help would be appreciated.
Version of gdbserver and that of host gdb are both Ubuntu 8.1.1-0ubuntu1. The remote system is aarch64.
So step 6 was working at one point. I don't know what I'm doing now differently to make the relocation no longer work.
I suspect that you have upgraded your toolchain, and that your upgraded toolchain produces a Position-Independent Executable mybinary by default, where the old toolchain didn't.
Try adding -no-pie to the link line of mybinary.
Obviously the unrelocated address doesn't work.
Actually, this does work for local debugging -- GDB is smart enough to realize that the code got loaded at a different address:
gdb -q a.out
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x112d: file t.c, line 1. <<< Note: unrelocated address
(gdb) run
Starting program: /tmp/a.out
Breakpoint 1, main () at t.c:1
1 int main() {return 0; }
(gdb) p/x $pc
$1 = 0x55555555512d <<< Note: breakpoint worked.
It's possible that remote debugging doesn't work, although this worked fine for me using GDB-10.0:
strip a.out -o b.out
gdbserver :6006 ./b.out
Process ./b.out created; pid = 239653
Listening on port 6006
... in another window:
gdb -q ./a.out
Reading symbols from ./a.out...
(gdb) target remote :6006
Remote debugging using :6006
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/a8/97a1105e21dd270bd418fe58c441700a6d8ec5.debug...
0x00007ffff7fe4940 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb) b main
Breakpoint 1 at 0x55555555512d: file t.c, line 1.
I have an embedded ARM application which is bundled with all the so-libraries stripped, including the libpthread.so. Sometimes the application gets stuck in some part of code and I want to be able to attach to it with gdb and see what's going on. The problem is that gdb refuses to load the needed threading support library, with the following messages:
Trying host libthread_db library: /home/me/debug_libs/libthread_db.so.1.
td_ta_new failed: application not linked with libthread
thread_db_load_search returning 0
warning: Unable to find libthread_db matching inferior's thread
library, thread debugging will not be available.
Because of this I cannot debug the application, e.g. I cannot see current call stacks for all threads.
After some investigation I suspect that the td_ta_new failing with the application not linked with libthread is caused by the stripped version of libpthread, which lacks the nptl_version symbol. Is there any way to bypass the error?
The gdb is compiled for ARM and being run on the device itself. I have unstripped versions of the libraries, but the application is already running with the stripped libraries.
Is there any way to bypass the error?
A few ways that come to mind:
Use add-symbol-file to override the stripped libpthread.so.0 with un-stripped one:
(gdb) info shared libpthread.so
# shows the path and memory address where stripped libpthread.so.0 is loaded
(gdb) add-symbol-file /path/to/unstripped/libpthread.so.0 $address
# should override with new symbols, and attempt to re-load libthread_db.so.1
Run gdb -ex 'set sysroot /path/to/unstripped' ... where /path/to/unstripped is the path that mirrors installed tree (that is, if you are using /lib/libpthread.so.0, there should be /path/to/unstripped/lib/libpthread.so.0.
I have not tested this, but I believe it should work.
You could comment out the version check in GDB and rebuild it.
I use this (http://cs.baylor.edu/~donahoo/tools/gdb/tutorial.html) guide to learn how GDB works.
After compiling and uploading the code to my embedded linux arm platform I use a remote connection to connect with the gdbserver on my target:
Target:
root#zedboard-zynq7:/Software# gdbserver HOST:1234 broken
Process broken created; pid = 1103
Listening on port 1234
Remote debugging from host 192.168.178.32
Host (Ubuntu 14.04 running in a virtual machine):
Remote debugging using 192.168.178.33:1234
warning: A handler for the OS ABI "GNU/Linux" is not built into this
configuration of GDB. Attempting to continue with the default arm settings.
Cannot access memory at address 0x0
0x43330d40 in ?? ()
(gdb)
I set the breakpoint to line 43 and continue the program until it stops at the breakpoint:
(gdb) b 43
Breakpoint 1 at 0x8b68: file broken.cpp, line 43.
(gdb) continue
Continuing.
Breakpoint 1, main () at broken.cpp:43
43 double seriesValue = ComputeSeriesValue(x, n);
(gdb)
But after a step call on my host I got this error:
Host:
warning: Remote failure reply: E01
Ignoring packet error, continuing...
Target:
ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
What does it mean and how can I fix it?
Thanks for help.
Host (Ubuntu 14.04 running in a virtual machine):
Remote debugging using 192.168.178.33:1234
warning: A handler for the OS ABI "GNU/Linux" is not built into this
configuration of GDB. Attempting to continue with the default arm settings.`
This says that your (host) GDB has not been built with support for the target you want to debug.
What does it mean and how can I fix it?
You need to either get a different build of (host) GDB, or build one yourself with correct --target setting.
Usually a correct host GDB is included with the cross-gcc that you use to build for your target. So a fix may be as simple as running /path/to/cross-gdb instead of gdb.
I am using gdb and gdbserver for debugging my exe. My target is same as local host currently. I start the gdbserver using
gdbserver.exe :6000 MyTest.exe 1> NUL 2> NUL
and my gdb is started using
gdb.exe -ex "set target-async on" -ex "target remote :6000"
But when I try info threads or set or get a global variable , I get cannot execute command target running. I tried to use interrupt before set but this doesn't change anything. Does any one know what could be wrong or what I'm doing wrong?
There is no input file to the gdb.exe in your code. Provide the same MyTest.exe file to gdb on host so that gdb can load the symbols
gdb.exe MYTest.exe
(gdb)set target-async on
(gdb)set target remote :6000
Qemu terminated with the log : "QEMU: Terminated via GDBstub" when I tried to connect to QEmu from GDB .
I started the QEMU with the following command in one terminal :
qemu-system-arm -serial telnet:localhost:1235,server,nowait,ipv4 -serial telnet:localhost:1236,server,nowait,ipv4 -serial telnet:localhost:1238,server,nowait,ipv4 -gdb tcp:localhost:1234,server,ipv4 -kernel ./build/final.elf -M versatilepb -nographic -m 256 -S
And then in another terminal I started GDB with the command :
arm-none-eabi-gdb --command=~/.gdbinit
And the file .gdbinit contains the text:
set history save on
set logging on
target remote localhost:1234
load ./build/final.elf
sym ./build/final.elf
b break_virtual
Can you please let me know whats going wrong here?
GDB automagically loads ~/.gdbinit
so when you load .gdbinit via --command=~/.gdbinit
it runs the script twice,
when it gets to the 2nd invocation of target remote localhost:1234
gdb hangs up its initial connection, qemu quits,
then gdb fails to reconnect to it because it is no longer running.
Either get rid of the --command option or rename the file.