如何在QEMU用户模式下GDB逐步调试动态链接的可执行文件? [英] How to GDB step debug a dynamically linked executable in QEMU user mode?
问题描述
例如对于ARM,如果我进行静态编译,则一切正常:
For example for ARM, if I compile statically, all works fine:
sudo apt-get install gdb-multiarch gcc-arm-linux-gnueabihf qemu-user
printf '
#include <stdio.h>
#include <stdlib.h>
int main() {
puts("hello world");
return EXIT_SUCCESS;
}
' > hello_world.c
arm-linux-gnueabihf-gcc -ggdb3 -static -o hello_world hello_world.c
qemu-arm -L /usr/arm-linux-gnueabihf -g 1234 ./hello_world
在另一个终端上:
gdb-multiarch -q --nh \
-ex 'set architecture arm' \
-ex 'set sysroot /usr/arm-linux-gnueabihf' \
-ex 'file hello_world' \
-ex 'target remote localhost:1234' \
-ex 'break main' \
-ex continue \
;
这使我留在main
,我可以像往常一样看到源代码和步骤调试.
This leaves me at main
, and I can see the source and step debug as usual.
但是,如果我删除了-static
,并保持其他所有内容不变,我的断点将永远不会被命中,并且程序将运行直到完成:
However, if I remove the -static
, and keep everything else unchanged, my breakpoint never gets hit, and the program runs until completion:
The target architecture is assumed to be arm
Reading symbols from hello_world...done.
Remote debugging using localhost:1234
Reading symbols from /usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3...(no debugging symbols found)...done.
0xff7b3b80 in ?? () from /usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3
Breakpoint 1 at 0x50c: file hello_world.c, line 5.
Continuing.
[Inferior 1 (Remote target) exited normally]
可执行文件本身运行正常,但是:
The executable itself does work fine however:
qemu-arm -L /usr/arm-linux-gnueabihf ./hello_world
打印:
hello world
我看过:如何单步ARM在Qemu上使用GDB进行汇编吗?,但是它没有专门涉及动态链接的可执行文件.
I have seen: How to single step ARM assembler in GDB on Qemu? but it didn't cover the case of dynamically linked executables specifically.
在Ubuntu 18.04,gdb-multiarch 8.1-0ubuntu3,gcc-arm-linux-gnueabihf 4:7.3.0-3ubuntu2,qemu-user 1:2.11 + dfsg-1ubuntu7.3.上进行了测试.
Tested on Ubuntu 18.04, gdb-multiarch 8.1-0ubuntu3, gcc-arm-linux-gnueabihf 4:7.3.0-3ubuntu2, qemu-user 1:2.11+dfsg-1ubuntu7.3.
工作正常的crosstool-ng设置
作为一个健全性检查,我尝试使用crosstool-ng获得干净的工具链,并且可以正常工作:
As a sanity check, I tried to get a clean toolchain with crosstool-ng, and it worked:
git clone https://github.com/crosstool-ng/crosstool-ng
cd crosstool-ng
git checkout d5900debd397b8909d9cafeb9a1093fb7a5dc6e6
export CT_PREFIX="$(pwd)/.build/ct_prefix"
./bootstrap
./configure --enable-local
./ct-ng arm-cortex_a15-linux-gnueabihf
# Has to be older than host kernel, which is 4.15.
printf "
CT_LINUX_V_4_14=y
CT_LINUX_VERSION=\"4.14.0\"
" >> .config
./ct-ng oldconfig
env -u LD_LIBRARY_PATH time ./ct-ng build -j`nproc`
cd ..
crosstool-ng/.build/ct_prefix/arm-cortex_a15-linux-gnueabihf/bin/arm-cortex_a15-linux-gnueabihf-gcc -ggdb3 -o hello_world hello_world.c -ggdb3 -static -o hello_world hello_world.c
qemu-arm -L crosstool-ng/.build/ct_prefix/arm-cortex_a15-linux-gnueabihf/arm-cortex_a15-linux-gnueabihf/sysroot -g 1234 ./hello_world
在另一个外壳上:
./.build/ct_prefix/arm-cortex_a15-linux-gnueabihf/bin/arm-cortex_a15-linux-gnueabihf-gdb \
-q --nh \
-ex 'set architecture arm' \
-ex 'set sysroot crosstool-ng/.build/ct_prefix/arm-cortex_a15-linux-gnueabihf/arm-cortex_a15-linux-gnueabihf/sysroot' \
-ex 'file hello_world' \
-ex 'target remote localhost:1234' \
-ex 'break main' \
-ex continue \
;
它还可以与gdb-multiarch
提供的发行版一起使用.
And it also works with the distro provided gdb-multiarch
.
推荐答案
失败是由于-pie -fpie
引起的,并且在以下位置有错误报告:
The failure is due to -pie -fpie
, and there is a bug report for it at: https://bugs.launchpad.net/qemu/+bug/1528239
显式设置-no-pie -fno-pie
使其可以同时在crosstool-ng和Ubuntu主机上工作.
Explicitly setting -no-pie -fno-pie
makes it work on both crosstool-ng and Ubuntu host.
区别在于,Ubuntu的默认情况下已构建了GCC以使用-fpie
,而我的crosstool-ng则没有.
The difference is that the Ubuntu one has GCC built to use -fpie
by default, while my crosstool-ng build did not.
可以通过以下方式进行检查:
This can be checked with:
gcc -v
主机GCC上包含的内容:
which on the host GCC contains:
--enable-default-pie
但不在crosstool-ng构建中.
but not in the crosstool-ng build.
我是怎么发现的:前一天,我在玩-fpie
时,发现在这种情况下,.text
地址真的很小:
How I found this out: the other day I was playing around with -fpie
and I noticed that the .text
addresses were really small in that case: What is the -fPIE option for position-independent executables in gcc and ld?
然后我看到打包的工具链的中断地址很小,并建立了链接.
Then I saw that the break address was very small with the packaged toolchain, and made the link.
这篇关于如何在QEMU用户模式下GDB逐步调试动态链接的可执行文件?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!