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

【问题标题】：Why does 64-bit gdb never reach breakpoint in ARM 32 code?为什么 64 位 gdb 在 ARM 32 代码中永远不会到达断点？
【发布时间】：2020-10-27 02:17:32
【问题描述】：

我正在运行 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 汇编语言课程的一部分）。这是我的工作：

$ 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。

【问题讨论】：

其实，我现在已经回答过了，但意识到也许我的假设是错误的。你在qemu 里面运行gdb 吗？
是的，我从客人那里做所有事情：vim，as，gdb。我不想进行远程调试。除了非常慢之外，这应该只是一个普通的 Ubuntu 20.04 服务器。我会尝试建议的 qemu 选项。
至于日志，我在 Proxmox 网络系统中看不到任何内容。至于命令，是的，我正在做客人的一切。至于交叉编译器，我不确定为什么要使用它。可能是因为我试图在 64 位系统上组装 32 位代码？（我在很多方面都是新手！）也许我的问题应该是，“我如何组装、运行和调试与我用来在 64 位系统上教授课程的教科书相匹配的代码（我可以找不到适用于 32 位 ARM 的 Ubuntu 20.04）。”教科书是 Kris Schindler 的《使用 ARM 处理器的基于微处理器的系统简介》。谢谢。
我已经使用原生 ARM 硬件从 AWS 上重现了 EC2 上的问题，因此该问题与 Proxmox 和 qemu 无关。我怀疑这是bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200的回归。
以bugs.launchpad.net/ubuntu/+source/gdb/+bug/1901966的身份向gdb报告。

标签： debugging assembly arm gdb

【解决方案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 的网站）

【讨论】：

我希望 gdb 在客户机内部执行，所以这根本没有帮助。