gdb `list` 命令在附加到进程时只显示一个行号而不是内容
gdb `list` command only shows one line number instead of contents when attaching to a process
我使用此命令 sudo gdb binary PID
调用了 gdb 以附加当前 运行 进程。之后我设置断点并在 gdb 中输入 continue
。然后我向这个进程发送了一个命中断点的请求。之后,当我键入命令 list
时,它只显示一行而不是预期的多行,并且只显示行号而不是内容。请问命令 n
的输出是什么意思?在互联网上,一些文档提到它意味着要执行的下一行。但是从输出本身来看,它对我来说并没有太大意义(在两个 n
命令之后,最后一个 l
命令显示 169 而不是 172 或 174)。谁能帮忙回答以上两个问题?非常感谢。
(gdb) l
164 in CBFEMultiSectionResponseModule.cc
(gdb) n
172 in CBFEMultiSectionResponseModule.cc
(gdb) l
167 in CBFEMultiSectionResponseModule.cc
(gdb) n
174 in CBFEMultiSectionResponseModule.cc
(gdb) l
169 in CBFEMultiSectionResponseModule.cc
这个源文件的构建命令行是这样的:
/usr/bin/g++ -c -fPIC -DMODULEADAPTER_BUILTIN_VERSION=\"2.36.375.10894.aff30c2\" -DLINUX -D_GNU_SOURCE -D_THREAD_SAFE -DUSE_STD_YUTSTRING -I../api -I. -I/home/y/include/ydisc \
-I/home/y/include/avro -I../.. -I../../.. -I../../../external_interfaces -I../../../sg_interfaces -I/home/y/include64 -I/home/y/include
\-fPIC -g -O2 -Wall -Werror -Wno-invalid-offsetof -fno-strict-aliasing -pipe -MD -MP
\-DYAHOO_PLATFORM_MAJOR=6 -DYAHOO_PLATFORM_MINOR=10 CBFEMultiSectionResponseModule.cc -o x86_64-linux-gcc/CBFEMultiSectionResponseModule.o
这是文件系统类型:
-bash-4.1$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
/dev/vda1 ext4 246G 97G 137G 42% /
tmpfs tmpfs 12G 30M 12G 1% /dev/shm
下面是info source
的输出:
(gdb) info source
Current source file is CBFEMultiSectionResponseModule.cc
Compilation directory is /home/myusername/ufe/modules/multisectionresponse/impl
Source language is c++.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
下面是shell cat
的输出:
(gdb) shell cat /home/myusername/ufe/modules/multisectionresponse/impl/CBFEMultiSectionResponseModule.cc
cat: /home/myusername/ufe/modules/multisectionresponse/impl/CBFEMultiSectionResponseModule.cc: No such file or directory
when I type command list, it only shows one line instead of multiple lines as expected, and it only shows line number instead of contents
这很可能发生,因为 GDB 无法访问源代码。 sudo
是这里的关键。您的源可能驻留在不允许根访问的文件系统上,例如 NFS。
it doesn't make too much sense to me(after two n commands the last l command shows 169 instead of 172 or 174).
您正在调试优化代码。参见例如this answer.
更新:
The path to source is correct in the compilation environment. However, the runtime environment is different than the compilation env ..
嗯,你为什么不告诉我们那个?
我的回答是正确的:GDB 没有列出源,因为源是不可访问的(它只是因为与我猜测的不同的原因而无法访问)。
如果您希望 GDB list
命令在运行时环境中工作,那么您必须 使源可用(尽管不一定在同一位置;使用 dir
命令将 GDB 指向源可用的位置。
更新二:
. I used to think GDB has some magic ways to get the source code from the binary.
二进制文件不包含源代码(这会变得更大)。相反,它包含 对源位置的引用。
特别是,编译器将每个翻译单元(每个 .cpp
文件)编码为二进制文件:
- 编译目录
- 源文件的名称(由于
#include
s,可能有多个)。
- 从程序计数器到 file/line 的映射,特定程序集块是为其生成的。
(还有描述变量位置、类型等的附加信息。但这些与 list
命令无关。)
GDB 将上面的代码解码为,定位源文件,并允许您通过 file/line 设置断点,在遇到断点时列出源等。
我使用此命令 sudo gdb binary PID
调用了 gdb 以附加当前 运行 进程。之后我设置断点并在 gdb 中输入 continue
。然后我向这个进程发送了一个命中断点的请求。之后,当我键入命令 list
时,它只显示一行而不是预期的多行,并且只显示行号而不是内容。请问命令 n
的输出是什么意思?在互联网上,一些文档提到它意味着要执行的下一行。但是从输出本身来看,它对我来说并没有太大意义(在两个 n
命令之后,最后一个 l
命令显示 169 而不是 172 或 174)。谁能帮忙回答以上两个问题?非常感谢。
(gdb) l
164 in CBFEMultiSectionResponseModule.cc
(gdb) n
172 in CBFEMultiSectionResponseModule.cc
(gdb) l
167 in CBFEMultiSectionResponseModule.cc
(gdb) n
174 in CBFEMultiSectionResponseModule.cc
(gdb) l
169 in CBFEMultiSectionResponseModule.cc
这个源文件的构建命令行是这样的:
/usr/bin/g++ -c -fPIC -DMODULEADAPTER_BUILTIN_VERSION=\"2.36.375.10894.aff30c2\" -DLINUX -D_GNU_SOURCE -D_THREAD_SAFE -DUSE_STD_YUTSTRING -I../api -I. -I/home/y/include/ydisc \
-I/home/y/include/avro -I../.. -I../../.. -I../../../external_interfaces -I../../../sg_interfaces -I/home/y/include64 -I/home/y/include
\-fPIC -g -O2 -Wall -Werror -Wno-invalid-offsetof -fno-strict-aliasing -pipe -MD -MP
\-DYAHOO_PLATFORM_MAJOR=6 -DYAHOO_PLATFORM_MINOR=10 CBFEMultiSectionResponseModule.cc -o x86_64-linux-gcc/CBFEMultiSectionResponseModule.o
这是文件系统类型:
-bash-4.1$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
/dev/vda1 ext4 246G 97G 137G 42% /
tmpfs tmpfs 12G 30M 12G 1% /dev/shm
下面是info source
的输出:
(gdb) info source
Current source file is CBFEMultiSectionResponseModule.cc
Compilation directory is /home/myusername/ufe/modules/multisectionresponse/impl
Source language is c++.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
下面是shell cat
的输出:
(gdb) shell cat /home/myusername/ufe/modules/multisectionresponse/impl/CBFEMultiSectionResponseModule.cc
cat: /home/myusername/ufe/modules/multisectionresponse/impl/CBFEMultiSectionResponseModule.cc: No such file or directory
when I type command list, it only shows one line instead of multiple lines as expected, and it only shows line number instead of contents
这很可能发生,因为 GDB 无法访问源代码。 sudo
是这里的关键。您的源可能驻留在不允许根访问的文件系统上,例如 NFS。
it doesn't make too much sense to me(after two n commands the last l command shows 169 instead of 172 or 174).
您正在调试优化代码。参见例如this answer.
更新:
The path to source is correct in the compilation environment. However, the runtime environment is different than the compilation env ..
嗯,你为什么不告诉我们那个?
我的回答是正确的:GDB 没有列出源,因为源是不可访问的(它只是因为与我猜测的不同的原因而无法访问)。
如果您希望 GDB list
命令在运行时环境中工作,那么您必须 使源可用(尽管不一定在同一位置;使用 dir
命令将 GDB 指向源可用的位置。
更新二:
. I used to think GDB has some magic ways to get the source code from the binary.
二进制文件不包含源代码(这会变得更大)。相反,它包含 对源位置的引用。
特别是,编译器将每个翻译单元(每个 .cpp
文件)编码为二进制文件:
- 编译目录
- 源文件的名称(由于
#include
s,可能有多个)。 - 从程序计数器到 file/line 的映射,特定程序集块是为其生成的。
(还有描述变量位置、类型等的附加信息。但这些与 list
命令无关。)
GDB 将上面的代码解码为,定位源文件,并允许您通过 file/line 设置断点,在遇到断点时列出源等。