Is it possible to do
(gdb) add-inferior -copies 2 -exec <some-file>
and connect remote target :5039 and remote target :5040 simultaneously to inferiors 2 and 3?
No, this is not yet possible. This is the multi target project mentioned on the gdb wiki.
Related
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
I have been trying to debug my xv6 locally (It is a 32-bit code). But I am working on a 64 bit machine and my gdb is 64 bit. Whenever I type
make gdb
I encountered the following error
+ target remote localhost:26000
.gdbinit:23: Error in sourced command file:
localhost:26000: Connection timed out.
(gdb) target remote localhost:26000
localhost:26000: Connection timed out.
I have a .gdbinit file. I have the following line in it
target remote localhost:26000
It's returning an error at this line. I initially thought it is because of 32-bit architecture of my machine. But if I go to some other directory and type the same message in the gdb console I am receiving the same error. I can't actually understand why it should connect to localhost(i.e what is need of a server here? ) as GDB is a normal GNU debugger right? and what is the reason for its failure in the above case?
Thanks in advance
Your question doesn't make any sense (to me).
As far as I can tell, you are asking: "why does GDB try to connect to localhost:2600".
The answer is: because you asked GDB to do so with the target remote localhost:26000 entry in your ~/.gdbinit.
Update:
I am asking what does that command do?
It instructs GDB to perform remote debugging, and to connect to gdbserver listening on the given port.
In general, you should never put anything into your ~/.gdbinit (or any other initialization file) that you don't understand. Doing so is akin to to taking an unknown object (a gun), putting it to your head, and squeezing a little lever on the side (a trigger).
and executing it giving me the above error so can you please say what is the error? and how to resolve it
Just delete the command (and any other commands that you don't know the meaning of) from ~/.gdbinit.
I've just solved the same problem u described. U can have a look at the GNUmakefile to search the port number your gdb-qemu attempted to connect to. In my GNUmakefile, the port number is
# try to generate a unique GDB port
GDBPORT := $(shell exprid -u% 5000 + 25000)
So when I try to run sudo make gdb-qemu, I got the result as follows:
qemu-system-i386 -drive file=obj/kern/kernel.img,index=0,media=disk,format=raw -serial mon:stdio -gdb tcp::25000 -D qemu.log -S
But when I run another terminal to run sudo make gdb, I got the result:
Type "apropos word" to search for commands related to "word".
+ target remote localhost:26000
The port number didn't match.
So by simply modify the port number in the GNUmakefile to 26000, we can get the ideal results.
Hope it's helpful :)
I had ever met the same problem as you. I had been troubled by this problem for hours.
But this problem is so easy.Please excute the following commands .
make qemu-gdb
make gdb (in another terminal.)
The reason for this problem is that when you execute the make gdb command, you end the execution of the make gdb .So the qemu server connection timed out .
In the picture, we can't alse find the infomation like remote gdb port...
You should change the port in the .gdbint file. It tells GDB which port to detach. I solved this problem in this way.
Im trying to attach DDD to gdb on a remote machine. I have configured rsh to not require a pass for my machine & username.
ddd opens with "rtx5:1234: not found" and a pop-up with "GDB could not be started". From calling ddd --host rtx5:2159 --trace --no-exec-window /home/murray/beer-process
# Running GDB (pid 2826, tty /dev/pts/1)...
# Current language: C/C++
# Searching "vsllib/ddd.vsl"...
# Trying "/home/murray/.ddd/vsllib/ddd.vsl"
# Trying "/usr/share/ddd-3.3.12/vsllib/ddd.vsl"
# Searching "vsllib/ddd.vsl"..."/usr/share/ddd-3.3.12/vsllib/ddd.vsl".
<- "sh: line 0: exec: rtx5:2159: not found\n"
# Running GDB (pid 2826, tty /dev/pts/1)...Exit 127.
The PID of GDB started by ddd from the trace logs are 4-digits. However, all the PIDs that I can see from the rtx(target) are 8-digit. I can not see gdb as a process yet the trace log indicates otherwise. Is the documentation out of date and I am invoking it incorrectly? How could I test if ddd is correctly rsh-ing?
I have addressed the caveats of the docs 2.4.1:
Beer-process binary is in the home dir of my username on the target.
Checked the path of gdb in /usr/bin/gdb
rtx5 does not have xterm therefore include --no-exec-window flag
Thanks in advance
TLDR: Had a firewall on the host interfering only with ddd's rsh connection. I also had to substitute "rtx5" for "'rsh rtx5'". It wont find the program I pass it, even though its in the home directory of the remote target. I can however use ddd-gui to find, load, and debug it.
I could rsh to rtx5 without a password, then call gdb.
I could not do "rsh rtx5 gdb" and have gdb start. This is due to rsh. When rsh is called without a command it operates out of 514. If rsh in called with a command it communicates and attempts to move to a different port number. This is where my firewall was blocking it.
Wireshark showed me from local to target after rsh connection:
destination unreachable (host administratively protected)
ddd still has issues primarily that I can not load a binary which is in my remote home directory. This extends problem extends to attaching to running processes on the remote host. In both cases I can load/connect via the gui once the connection is established.
Furthermore I have to call ddd with 'rsh ' prepended to the remote-host name. This seems wrong. I'll update when I have more.
I am trying to debug Linux kernel with kvm vm. I am getting an error message "Remote 'g' packet reply is too long". My host is 64-bit and so is my vm.
My steps:
Start the VM with custom -kernel, -initrd and -append options.
Start gdb
Execute "set architecture i386:x86-64:intel"
Execute "add-symbol-file linux-3.0/vmlinux"
Execute "show arch" to verify its still "i386:x86-64:intel"
Execute "target remote localhost:1234"
Execute "continue"
Press Ctrl+C, I get the above message.
Has anyone faced this problem?
gdb doesn't work well against a cpu that switches between instruction sets at runtime. Wait for the kernel to leave early boot before connecting, and don't use qemu's -S flag.
I also faced same issue, I fixed it by modifying gdbstub.c (in qemu sources) to send 64bit registers always and hinting GDB that architecture is 64bit by passing set arch i386:x86-64
You can check the patch here:
Visit [URL no longer available]
I found a similar problem (& this question) connecting gdb very early in the boot process – as mentioned in other answers, gdb does not very much appreciate the size of registers changing out from under it. This problem can be seen by using set debug remote 1:
(gdb) set debug remote 1
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
...
Sending packet: $g#67...Ack
Packet received: 000000000000000... <~600 bytes>
(gdb) until *0x1000 # at this address we'll be in a different cpu mode
...
Sending packet: $g#67...Ack
Packet received: 10000080000000000000000000000000800000c... <~1000 bytes>
...
Remote 'g' packet reply is too long: 1000008000000000000000000...
(gdb)
Patching gdb to resize its internal buffer when it sees a too-large packet
as found on this issue in the gdb bug tracker (and elsewhere), does indeed work around the problem, as does patching QEMU to only send 64-bit-sized packets. However, the latter solution breaks debugging in non-64-bit-modes, and it seems that the former fix could be incomplete:
It sounds quite wrong to be changing the target behind
GDB's back when GDB is already debugging it. Not just the size
of the g/G packets may change inadvertently, but the layout as well.
If the target description changes with your re-configuration, it
sounds to me like GDB should fetch/recompute the whole target
description. Today, I think that can only be done with a
disconnect/reconnect.
– https://sourceware.org/ml/gdb/2014-02/msg00005.html
The disconnect/reconnect workaround mentioned at the end of the post does appear to work:
(gdb) disconnect
Ending remote debugging.
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
(gdb) info registers
rax 0x80000010 2147483664
rbx 0x0 0
...
I had accidentally omitted the binary name as an argument to gdb. So this worked for me.
$ gdb ./vmlinux
(gdb) target remote localhost:1234
And then got the Output :
Remote debugging using localhost:1234
0xffffffff81025f96 in default_idle ()
The debugger needs vmlinux so make sure you provide it. OP has a different problem, But my answer might help to those who forgot to provide argument to gdb and ended up with the same error message as OP.
I'm trying to debug a server I wrote with gdb as it segfaults under very specific and rare conditions.
Is there any way I can make gdb run in the background (via quiet or batch mode?), follow children (as my server is a daemon and detaches from the main PID) and automatically dump the core and the backtrace (to a designated file) once the program crashes?
Assuming you have appropriate permissions, you can have gdb attach to any process. You can do it on the command line with:
gdb /path/to/binary _pid_
or from within gdb with the attach command:
attach _pid_
So, once your daemon has started, you can use either of these techniques to attach to the final PID your daemon is running as. Attaching gdb stops the process which you are tracing so you will need to issue a "continue" to restart it.
I don't know a direct way to get gdb to run arbitrary commands when the program crashes. Here is one workaround I can think of:
Create and register a signal handlers for SIGSEGV.
Tell gdb not to stop on that signal (handle SIGSEGV nostop)
Set a breakpoint at the first line of your signal handler.
Assign commands to the breakpoint from step 3
Why not just run the process interactively in a persistent screen session? Why must it be a daemon when debugging? Or just run gdb in the screen session and attach it to the running process (e.g. gdb /path/to/binary -p PID_of_binary) after it forks.
First, I'd setup your shell / environment to give you a core dump. In bash:
ulimit -c unlimited
Once you have the core dump, you can use gdb to examine the stack trace:
gdb /path/to/app /path/to/core/file
I'm not really a gdb expert but two things come to mind
Tracepoints which might give you the necessary information as your program runs or
Use gdb's remote debugging facility to debug your program while it's running as a daemon.
How to generate a stacktrace when my gcc C++ app crashes answer for this question should do what you want. (assuming you can make changes in your code)
You might want to take a look at how Samba facilitates debugging; it has a configurable "panic action" that can suspend the application, notify the developer, spawn gdb, etc., and is run as part of its signal handler. See lib/util/fault.c in the Samba source tree.
My practice: comment out daemon function call, rebuild binary, then use gdb to run.