AArch64 的 QEMU：为什么执行停留在“ldr q1，[x0]”？

Question

我有这个简单的 C 代码：

#include "uart.h"
#include <string.h>
char x[32];
__attribute__((noinline))
void foo(void)
{
    strcpy(x, "xxxxxxxxxxxxxxxxxxxxxxxx");
}
int main(void)
{
  uart_puts("xxx\n");
  foo();
  uart_puts("yyy\n");
}

编译为：

$ aarch64-none-elf-gcc t78.c -mcpu=cortex-a57 -Wall -Wextra -g -O2 -c -std=c11 \
&& aarch64-none-elf-ld -T linker.ld t78.o boot.o uart.o -o kernel.elf

并执行为：

$ qemu-system-aarch64.exe -machine virt -cpu cortex-a57 -nographic -kernel kernel.elf

印刷：

xxx

为什么不打印yyy ？

通过减少问题，我发现：

1. 对于strcpy GCC 生成的代码不是“调用 strcpy”（见下文）
2. ldr q1, [x0]导致不打印yyy 。

这是foo的生成代码：

foo:
.LFB0:
        .file 1 "t78.c"
        .loc 1 6 1 view -0
        .cfi_startproc
        .loc 1 7 5 view .LVU1
        adrp    x0, .LC0
        add     x0, x0, :lo12:.LC0
        adrp    x1, .LANCHOR0
        add     x2, x1, :lo12:.LANCHOR0
        ldr     q1, [x0]                     <<== root cause
        ldr     q0, [x0, 9]
        str     q1, [x1, #:lo12:.LANCHOR0]
        str     q0, [x2, 9]
        .loc 1 8 1 is_stmt 0 view .LVU2
        ret

如果我将ret放在ldr q1, [x0]将打印yyy （预期为 ax）。

问题：为什么ldr q1, [x0]导致不打印yyy ？

工具版本：

$ aarch64-none-elf-gcc --version
aarch64-none-elf-gcc.exe (Arm GNU Toolchain 12.2.Rel1 (Build arm-12.24)) 12.2.1 20221205

$ qemu-system-aarch64 --version
QEMU emulator version 7.2.0 (v7.2.0-11948-ge6523b71fc-dirty)

Answer 1

ldr q1, [x0]指令出现异常，因为它访问浮点/SIMD 寄存器，但您的启动代码未启用 FPU。 编译器假设它可以生成使用 FPU 的代码，因此为了满足该假设，您的启动代码必须做的一件事是启用 FPU，至少通过 CPACR_EL1，如果启用了 EL2 或 EL3，还可能通过其他寄存器。

或者，您可以告诉编译器不要发出使用 FPU 的代码。 Linux kernel 采用这种方法，使用-mgeneral-regs-only选项。

真正的硬件可能对配置 CPU 能够运行 C 代码所需的操作有更严格的要求； QEMU 相当宽松。 例如，架构定义许多系统寄存器的重置值是未知的，尽管 QEMU 通常将它们重置为零。 稳健的启动序列将显式设置寄存器中的位，例如 SCTLR_EL1。

您可能还需要注意编译器和启动代码是否同意编译器生成的代码是否允许发出未对齐的访问——如果未启用 MMU，则所有 memory 访问都被视为设备类型，这意味着它们必须对齐（不管 SCTLR_EL1.A）。 因此，您需要确保您的编译器不会尝试发出未对齐的加载和存储，或者打开 MMU 并将 SCTLR_EL1.A 设置为 0。

您可以通过安装一些异常向量来提高调试此类“早期启动异常”的能力，这些异常向量在发生意外异常时会做一些有用的事情。 理想的是能够打印寄存器，尤其是 ELR_EL1 和 ESR_EL1，它们会告诉您异常发生的位置和原因； 不过，在早期启动时打印可能很棘手。 一个简单的妥协是至少捕获异常和循环； 然后你可以使用 gdb 查看 CPU state 是什么。

Answer 2

Peter Maydell 的补充回答。

这是启用 FPU 的代码（在此处找到）：

mrs    x1, cpacr_el1
mov    x0, #(3 << 20)
orr    x0, x1, x0
msr    cpacr_el1, x0