C语言 致命信号:当加载符号文件后检查vertain地址值时,gdb中出现分段错误

ddarikpa  于 2023-05-28  发布在  其他
关注(0)|答案(2)|浏览(122)

我的环境:

  • 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的工作原理和我预期的一样,但我很困惑,为什么在获取某个地址的值时会出现分段错误。在本例中,我尝试在0xc0010f640xc0010f6c处获取指令,结果证明没有问题。

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工作正常,那么我想知道发生了什么?
谢谢!

izkcnapc

izkcnapc1#

所以我想知道发生了什么
很明显,GDB中有一个bug。
但是对于任何比这更明确的东西,您需要制作一个可复制的测试用例,或者至少使用gdb-multiarch的非剥离版本,以便可以识别其中的崩溃函数。

wvyml7n5

wvyml7n52#

我通过避免-fstrength-reduce解决了这个问题。我猜这个选项编译的一些指令在gdb中无法识别?

相关问题