为什么64位gdb在ARM32代码中永远不会到达断点

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 Fridayn"
        .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"(。我可以按如下方式分解代码：

$ 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汇编语言课程的一部分(。我是这样做的：

$ 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位有关。

A"；固定的"；gdb中的bug似乎非常相似。看看这个和这个。

Answer 1

如果gdb在主机上的qemu的外部运行，则会回答此问题。这个问题并非如此

---

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

在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的网站(