基于GNU-EFI开发的x86_64 Hello World OS在QEMU中启动后卡死问题求助

针对你遇到的GNU-EFI Hello World OS在QEMU启动时卡死的问题，结合你的Arch Linux环境和代码仓库，我整理了几个关键的排查方向和解决思路，你可以一步步来验证：

1. 核对GNU-EFI的编译配置细节 #

Makefile的配置错误是这类问题的高发区，重点检查这几点：

• 确认GNUEFI_PATH指向Arch系统中正确的GNU-EFI安装路径：官方包的话通常是/usr/lib/gnuefi，如果是手动编译的要对应到实际目录，确保include和lib子目录存在。
• 检查编译目标是否明确指定x86_64架构，比如ARCH = x86_64，链接时必须使用elf_x86_64_efi.lds脚本，保证生成符合EFI规范的PE/COFF格式文件。
• 验证efi_main函数的签名绝对正确：EFI_STATUS EFIAPI efi_main(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)，签名不符会导致EFI无法调用入口点，直接卡死。

2. 确认OVMF镜像的完整性与兼容性 #

• 优先使用Arch官方的edk2-ovmf包安装OVMF，路径是/usr/share/edk2/x64/OVMF_CODE.fd和OVMF_VARS.fd，手动下载的要确保是x86_64稳定版，旧版本可能存在兼容性bug。
• 重置OVMF变量镜像：删除现有OVMF_VARS.fd，从包中复制一份干净的，避免旧的配置干扰启动流程。

3. 检查生成的磁盘镜像文件系统 #

EFI仅识别FAT文件系统，这一步不能出错：

• 用fdisk -l $(BUILD_DIR)/$(OSNAME).img检查分区类型是否为EFI系统分区（类型代码EF00）。
• 挂载镜像后，确认EFI/BOOT/BOOTX64.EFI存在且是正确的编译产物，用objdump -h $(BUILD_DIR)/BOOTX64.EFI验证是否为有效的PE/COFF文件。

4. 调整QEMU启动参数获取更多信息 #

• 添加调试参数：-debugcon file:debug.log -global isa-debugcon.iobase=0x402，EFI的调试日志会输出到debug.log，能看到卡死前的执行细节，比如加载引导程序后的错误信息。
• 简化CPU参数：去掉-cpu qemu64，换成-cpu host或者直接省略，部分CPU模拟选项可能触发EFI运行异常。
• 明确磁盘参数：把硬盘驱动参数改成-drive file=$(BUILD_DIR)/$(OSNAME).img,format=raw,media=disk，避免QEMU自动识别出错。

5. 手动在EFI Shell中执行引导程序 #

直接启动QEMU进入EFI Shell，手动执行引导程序，定位问题环节：

sudo qemu-system-x86_64 -bios $(OVMF_DIR)/OVMF_CODE.fd -m 256M -net none

进入Shell后，输入fs0:切换到EFI分区，然后执行EFI\BOOT\BOOTX64.EFI，如果有报错信息会直接显示，能区分是文件系统问题还是引导程序本身的bug。

进阶调试：用GDB跟踪执行流程 #

如果以上步骤没找到问题，用GDB调试QEMU来定位卡死点：

1. 启动QEMU时添加暂停参数：

sudo qemu-system-x86_64 -drive file=$(BUILD_DIR)/$(OSNAME).img -m 256M \
-drive if=pflash,format=raw,unit=0,file="$(OVMF_DIR)/OVMF_CODE.fd",readonly=on \
-drive if=pflash,format=raw,unit=1,file="$(OVMF_DIR)/OVMF_VARS.fd" \
-net none -s -S

2. 打开新终端启动GDB，连接到QEMU：

gdb
(gdb) target remote localhost:1234
(gdb) add-symbol-file $(BUILD_DIR)/BOOTX64.EFI 0x100000  # EFI通常加载到0x100000附近
(gdb) break efi_main
(gdb) continue

如果能命中efi_main断点，说明引导程序被正确加载，问题出在代码执行过程中；如果没命中，说明EFI没找到或无法加载引导程序。

内容的提问来源于stack exchange，提问作者xubury