debugging - 为什么 64 位 gdb 永远不会在 ARM 32 代码中到达断点？

Question

我正在运行 Ubuntu 20.04.1 LTS 和 lscpu回答以下问题:

Architecture:                    aarch64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
CPU(s):                          4
On-line CPU(s) list:             0-3
Thread(s) per core:              1
Core(s) per socket:              4
Socket(s):                       1
NUMA node(s):                    1
Vendor ID:                       ARM
Model:                           0
Model name:                      Cortex-A57
Stepping:                        r1p0
BogoMIPS:                        125.00
NUMA node0 CPU(s):               0-3
Vulnerability Itlb multihit:     Not affected
Vulnerability L1tf:              Not affected
Vulnerability Mds:               Not affected
Vulnerability Meltdown:          Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:        Mitigation; __user pointer sanitization
Vulnerability Spectre v2:        Vulnerable
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

我创建了一个简单的汇编语言程序，如下所示:

        .text
        .global _start
_start:
        MOV     R0, #1
        LDR     R1, =hello
        LDR     R2, =hello_size
        MOV     R7, #4
        SWI     0
        MOV     R7, #1
        SWI     0

        .data
hello:  .asciz  "Happy Friday\n"
        .equ    hello_size, (.-hello)

我用以下内容编译它:

arm-linux-gnueabihf-as -ggdb hello.s -o out.o
arm-linux-gnueabihf-ld out.o -o out -lc -dynamic-linker=/usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3

当我直接从命令行运行它时，它会打印预期的输出(“Happy Friday\n”)。我可以按如下方式反汇编代码:

$ objdump -d out

out:     file format elf32-littlearm


Disassembly of section .text:

0001016c <_start>:
   1016c:   e3a00001    mov r0, #1
   10170:   e59f1010    ldr r1, [pc, #16]   ; 10188 <_start+0x1c>
   10174:   e59f2010    ldr r2, [pc, #16]   ; 1018c <_start+0x20>
   10178:   e3a07004    mov r7, #4
   1017c:   ef000000    svc 0x00000000
   10180:   e3a07001    mov r7, #1
   10184:   ef000000    svc 0x00000000
   10188:   0002100c    .word   0x0002100c
   1018c:   0000000e    .word   0x0000000e

我想在调试器中运行它(作为我正在教授 ARM 汇编语言的类(class)的一部分)。这是我所做的:

$ gdb out
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
...
Reading symbols from out...
(gdb) b _start
Breakpoint 1 at 0x1016c: file hello.s, line 4.
(gdb) run
Starting program: /home/fostja/code/280/samples/out 

此时程序挂起。中断程序给出以下结果:

^C
Program received signal SIGINT, Interrupt.
0x0000aaaadca1a284 in ?? ()
(gdb) bt
#0  0x0000aaaadca1a284 in ?? ()
#1  0x000000000000afc7 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

我不知道为什么它挂起并且永远不会到达第一个断点。起初我认为它与 Qemu 模拟应该在调试器中触发断点的指令有关(我首先在 Proxmox 上尝试了这个，所以大部分讨论都集中在那里)但现在它似乎与 32 有关位和 64 位。 gdb 中的“已修复”错误似乎很相似。见 this和 this .

Answer 1

这将回答它，如果 gdb在 qemu 之外运行，在主机上。这不是这个问题的情况。

您需要使用 gdbserver 在 qemu 中，然后连接到它。
在 qemu 中:

(qemu) gdbserver
gdbserver
Waiting for gdb connection on device 'tcp::1234'

在 gdb 中，您必须连接到它(可能需要调整以符合 qemu 的输出):

(gdb) target remote localhost:1234
Remote debugging using localhost:1234

来源: https://linux.postach.io/post/debugging-linux-kernel-using-virtual-machine-qemu-monitor-and-gdb (或几乎任何其他提到 gdbserver 和 qemu 的网站)