Question

我有一个相对简单的应用程序（链接在另一个简单的库中）拒绝让我使用gdb远程调试它。我检查过gdb和gdbserver版本是否匹配。它实际上在两台机器上都是相同的操作系统（ubuntu）。似乎很高兴从可执行文件中加载符号。因此，我可能会因为错误而感到有点失落。任何建议赞赏。这是来自gdb的成绩单：

dev:/fast/git/archive/foo$ gdb /fast/git/foo 
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.04) 7.11.1
Copyright (C) 2016 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-linux-gnu".
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 /fast/git/foo...done.
(gdb) target remote test1:5000
Remote debugging using test1:5000
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 /lib64/ld-2.23.so from remote target...
Reading /lib64/.debug/ld-2.23.so from remote target...
(no debugging symbols found)...done.
0x00007ffff7dd7cc0 in ?? () from target:/lib64/ld-linux-x86-64.so.2
(gdb) bt
#0  0x00007ffff7dd7cc0 in ?? () from target:/lib64/ld-linux-x86-64.so.2
#1  0x0000000000000003 in ?? ()
#2  0x00007fffffffce02 in ?? ()
#3  0x00007fffffffce2f in ?? ()
#4  0x00007fffffffce32 in ?? ()
#5  0x0000000000000000 in ?? ()

啊，太有趣了。我仍然不确定为什么，但它只在连接上打印（虚假堆栈跟踪）。如果我然后“继续”，如果我触发休息，它将很乐意打印正确的符号。

奇怪......也许这部分是用户错误，但我预计它会在我连接时开始运行并在主要开始时中断。

Answer 1

我对可能出错的东西感到有些失落

可能根本没有没有错误。

以下是我在本地机器上获得的信息：

gdbserver :0 /bin/date
Process /bin/date created; pid = 132826
Listening on port 57966
Remote debugging from host 127.0.0.1

在另一个窗口中：

gdb -q /bin/date
(gdb) target remote localhost:57966
Remote debugging using localhost:57966
Loading symbols for shared libraries.
Loading symbols for shared libraries.
0x00007ffff7ddb2d0 in _start () at rtld.c:871
871 rtld.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7ddb2d0 in _start () at rtld.c:871
#1  0x0000000000000001 in ?? ()
#2  0x00007fffffffe157 in ?? ()
#3  0x0000000000000000 in ?? ()

这里发生的事情是gdbserver很早就停止了劣质（被调试）进程。在加载器归零堆栈之前，以及在输入main之前。

应该已经加载了主可执行文件的符号，您应该可以在它们上设置断点。在main上设置断点，然后从那里继续，您很快就会看到断点被击中。

<强>更新

我预计它会在我连接时开始运行并在main的开始时中断。

您的期望不正确。

在典型的动态链接二进制文件中，_start与main之间有1000条指令。有时这些指令是发生崩溃的指令。如果GDB自动继续main而没有给你机会设置断点或观察点，那么调试此类崩溃将比现在困难得多。

Answer 2

一些想法：

确保使用-g编译远程程序和共享库以添加调试符号。 (no debugging symbols found)消息可能意味着整个可执行文件中缺少调试符号。

确保本地和远程程序是相同的图像。你可以对每个人做一个'总和'。这可能是问题，因为#1 0x0000000000000003 in ?? ()行看起来已损坏。

您是否可以手动调试远程盒子上的目标？如果是这样，请检查符号以查看是否有关于远程/本地调试会话的信息。您可以通过执行list <function>

来检查调试符号

地址范围通常在本地系统上与远程映射相同。您可以在本地调试会话中反汇编地址，并查看它映射到的函数/方法。如果远程程序崩溃，这可能会有所帮助，至少可以了解问题所在。

Answer 3

调试远程时，gdb客户端不知道从哪里加载符号。您有两种选择：

1. specify executable when starting gdb

gdb <executable>
(gdb) target remote <IP>:<port>
(gdb) load <executable>
 gdb should know symbols now
(gdb) b main
(gdb) mon reset
(gdb) contnue
 it should break at main
(gdb) bt

2. use file command to tell about the symbols.

gdb
(gdb) target remote <IP>:<port>
(gdb) load <executable>
(gdb) file <executable>
 gdb should know symbols now
(gdb) b main
(gdb) mon reset
(gdb) contnue
 it should break at main
(gdb) bt

远程gdb中的堆栈跟踪中没有符号（只是问号）

3 个答案: