我的环境:
Linux My-PC 5.15.90.1-microsoft-standard-WSL2 x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description: Ubuntu 22.04.1 LTS
GDB-多牙弓版本
$ gdb-multiarch -v
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Makefile的选定部分(忽略许多内容):
AS =arm-linux-gnueabihf-as
LD =arm-linux-gnueabihf-ld
NM =arm-linux-gnueabihf-nm
LDFLAGS =-Timx6ul.lds
CC =arm-linux-gnueabihf-gcc $(RAMDISK)
CFLAGS =-Wall -fomit-frame-pointer -nostdlib -fno-stack-protector -g
CPP =arm-linux-gnueabihf-cpp -nostdinc -Iinclude -lgcc -L/usr/lib/gcc-cross/arm-linux-gnueabihf/11 -g
.c.s:
$(CC) $(CFLAGS) \
-nostdinc -Iinclude -S -o $*.s $<
.s.o:
$(AS) -o $*.o $<
.c.o:
$(CC) $(CFLAGS) \
-nostdinc -Iinclude -c -o $*.o $<
all: Image
Image: boot/start tools/system
arm-linux-gnueabihf-objcopy -O binary -R .note -R .comment tools/system Image
sync
tools/system: init/main.o boot/start.o \
$(ARCHIVES) $(DRIVERS) $(MATH) $(LIBS)
mkdir -p tools
$(LD) $(LDFLAGS) init/main.o boot/start.o \
$(ARCHIVES) \
$(DRIVERS) \
$(MATH) \
$(LIBS) \
-o tools/system -lgcc -L /usr/lib/gcc-cross/arm-linux-gnueabihf/11
$(NM) -n tools/system > System.map
boot/start:boot/start.S
$(AS) -o boot/start.o boot/start.S
qemu: all
qemu-system-arm \
-machine virt,gic-version=3 \
-m 4G \
-cpu cortex-a7 \
-nographic \
-device loader,file=Image,addr=0xC0008000,cpu-num=0 \
-s -S
# -serial null -serial mon:stdio \
init.gdb:
target remote localhost:1234
set architecture arm
symbol-file tools/system
x/i 0xc0010f68
问题是,当我在gdb终端的某个地址检查值时,会发生此错误。对于成千上万的指令,gdb的工作原理和我预期的一样,但我很困惑,为什么在获取某个地址的值时会出现分段错误。在本例中,我尝试在0xc0010f64
和0xc0010f6c
处获取指令,结果证明没有问题。
Fatal signal: Segmentation fault
----- Backtrace -----
0x55e79b1e4197 ???
0x55e79b2e6599 ???
0x55e79b2e6762 ???
0x7f66f400951f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x55e79b64560c ???
0x55e79b6452c5 ???
0x55e79b646831 ???
0x55e79b6469c9 ???
0x55e79b2761b1 ???
0x55e79b27718b ???
0x55e79b4437d7 ???
0x55e79b447f4b ???
0x55e79b448a0c ???
0x55e79b219774 ???
0x55e79b5a9d94 ???
0x55e79b2e76e4 ???
0x55e79b5ab99e ???
0x55e79b228443 ???
0x55e79b2163b7 ???
0x55e79b3b1da5 ???
0x55e79b3b1e39 ???
0x55e79b3b38d3 ???
0x55e79b3b43fe ???
0x55e79b10e0ef ???
0x7f66f3ff0d8f __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f66f3ff0e3f __libc_start_main_impl
../csu/libc-start.c:392
0x55e79b113e24 ???
0xffffffffffffffff ???
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible. GDB will now terminate.
我还发现只有在symbol-file tools/system
执行时才会发生这种情况。如果gdb中没有加载符号,gdb工作正常,那么我想知道发生了什么?
谢谢!
2条答案
按热度按时间izkcnapc1#
所以我想知道发生了什么
很明显,GDB中有一个bug。
但是对于任何比这更明确的东西,您需要制作一个可复制的测试用例,或者至少使用
gdb-multiarch
的非剥离版本,以便可以识别其中的崩溃函数。wvyml7n52#
我通过避免
-fstrength-reduce
解决了这个问题。我猜这个选项编译的一些指令在gdb中无法识别?