Windows上Visual Studio Professional能否调试Ubuntu上QEMU运行的ARM64程序

核心结论 #

该调试场景无本质兼容性阻碍，完全可实现，通过对齐两端的调试配置即可打通从Visual Studio Professional发起的全链路调试流程。

已验证可用的前置能力 #

• Visual Studio直连x86架构Ubuntu开展原生程序远程调试的流程正常
• aarch64架构程序交叉编译流程正常，可产出带完整调试符号的可执行文件，对应编译命令为aarch64-linux-gnu-gcc -fno-pie -ggdb3 -no-pie -o hello hello.c
• Ubuntu本机已验证QEMU+gdb-multiarch的本地调试链路可正常运行，对应参考执行命令为：

# 启动带gdb stub调试服务的QEMU模拟进程
qemu-aarch64 -L /usr/aarch64-linux-gnu -g 1238 ./hello
# 本地gdb附加调试命令
gdb-multiarch -q --nh -ex 'set architecture arm64' -ex 'file hello' -ex 'target remote localhost:1238' -ex 'layout split' -ex 'layout regs'

测试示例程序本身无语法、编译问题，编译产出的hello可执行文件可在QEMU环境正常运行。

关键配置调整步骤 #

Ubuntu端适配 #

• 修改QEMU启动参数，将调试端口绑定到全网络可访问地址，替换原有的仅本地回环绑定配置：
  qemu-aarch64 -L /usr/aarch64-linux-gnu -g 0.0.0.0:1238 ./hello
• 放行系统防火墙对1238端口的访问限制，确保Windows主机可通过TCP协议连通该调试端口

Visual Studio端调试配置 #

• 打开对应Linux C++项目的调试属性页，将调试模式从默认的“自动远程启动gdbserver”切换为手动指定GDB远程连接目标模式
• 核心参数对齐：
• 替换默认的x86专用远程gdb，选择支持aarch64架构的multiarch版本gdb作为本地调试器
• 在GDB初始化参数中追加-ex "set architecture arm64"，和本地命令行调试的架构协商逻辑保持一致
• 远程目标地址填写<Ubuntu主机IP>:1238，对应QEMU gdb stub的监听地址
• 关闭“远程自动拉起调试服务进程”选项，避免VS在Ubuntu端重复启动gdbserver造成端口占用、通信链路冲突
• 配置本地调试符号的路径映射，确保VS端加载的符号文件和Ubuntu端运行的目标程序版本完全一致

常见附加失败诱因 #

• QEMU调试端口仅绑定127.0.0.1回环地址，跨主机网络访问被阻断
• 调试配置仍沿用原生gdbserver的自动启动逻辑，和QEMU自带的gdb stub通信机制不匹配
• 使用不支持aarch64架构的gdb版本发起连接，导致架构协商超时，VS端无明确报错提示
• 符号路径映射错误，gdb加载调试符号时无法和目标程序的地址空间正确匹配

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