前言
- 最近使用 VS Code GDB 调试 qemu，有了一点收获，u-boot 编译后生成了一个 elf 文件：u-boot，是否也可以调试一下？
- 为何需要 VS Code GDB 调试，直接 gdb 调试不就可以了吗？答案就是：VS Code 可以界面调试，命令行调试会枯燥很多
环境
- 使用 qemu，就是不需要板子
- win10 64位 VMware Workstation Pro 16
- ubuntu 20.04
- qemu （虚拟ARM开发板），
qemu arm64平台 - u-boot :
u-boot-2023.04 - gcc 交叉编译工具链：
gcc version 12.2.1 20230401
目标
- 基于 qemu，VS Code GDB，界面调试 u-boot，了解 u-boot 的启动流程
- qemu：不需要硬件电路板支持，当前一些启动初始化流程可能与实际电路板存在差异，所以目标就是摸清楚 u-boot 的启动流程，重在搞清楚 u-boot 启动与初始化流程。
- VS Code，这里重在界面调试，类似于 eclipse 那样的，可以源码调试
- GDB：是一个强大的调试工具
编译 u-boot
- 配置文件：
configs/qemu_arm64_defconfig - 生成配置：
make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- qemu_arm64_defconfig - 【备注】：当前
u-boot-2023.04ARM 与 ARM64 没有分开，所以ARCH=arm，而不是ARCH=arm64 - 开始编译：
make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- - 生成的产物：
u-boot.bin：二进制文件，u-boot： elf 可执行文件，默认包含 debug 信息
配置 VS Code gdb
- 当前 是 Win10 下 VS Code 通过 SSH 连接 VM虚拟机中的 ubuntu，如果本地是 ubuntu 系统，应该就不需要 SSH 远程连接
- VS Code 安装 gdb 调试插件
- 【备注】gdb 这个插件，好像不需要，确认下左边栏 是否有个 DEBUG 调试按钮吧，好像是 VS Code 自带的。
- 配置 VS Code 调试：点击 【设置】的按钮，会提示选择某个调试器，这里随便选择一个，然后就会出现一个
.vscode/launch.json文件 - 修改
launch.json文件内容如下
{
"version": "0.2.0",
"configurations": [
{
"name": "uboot-debug",
"type": "cppdbg",
"request": "launch",
"miDebuggerServerAddress": "127.0.0.1:1234",
"miDebuggerPath": "/home/zhangsz/linux/tools/gcc-linaro-12.2.1-2023.04-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gdb",
"program": "${workspaceFolder}/u-boot",
"args": [],
"stopAtEntry": true,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"logging": {
"engineLogging": false
},
"MIMode": "gdb",
}
]
}- 注意点一：
"miDebuggerPath": "/home/zhangsz/linux/tools/gcc-linaro-12.2.1-2023.04-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gdb",，这里设置 gcc gdb 的执行路径，全路径即可，这里的 gdb，来自gcc version 12.2.1 20230401交叉编译工具链 - 注意点二：
"program": "${workspaceFolder}/u-boot",，这里选择 u-boot，也就是 ELF 文件，而不是 u-boot.bin 二进制文件 - 注意点三：
"stopAtEntry": true,，这里选择 所有 的 执行 入口函数，都有断点停下来，否则可能 u-boot 无法调试
qemu 启动与调试脚本
- qemu 启动脚本：
qemu.sh，可以确认 u-boot 是否可以正常启动
#!/bin/bash
qemu-system-aarch64 -machine virt \
-nographic \
-m 512M \
-cpu cortex-a57 \
-kernel u-boot \- qemu 调试调试脚本，
qemu-debug.sh，执行此脚本，可以进入 qemu 调试
#!/bin/bash
qemu-system-aarch64 -machine virt \
-nographic \
-m 512M \
-cpu cortex-a57 \
-kernel u-boot \
-s -S调试方法
- 执行
qemu-debug.sh，此时会卡住，也就是 qemu 处于【冻结】状态 - 点击 调试图标的 【运行】按钮：
- 进入调试界面：
- 此时可以加断点进行调试，可以单步【F11】或者 【F10】进行调试
- 如此， VS Code gdb 源码调试 u-boot 的环境搭建成功了
备注
- 好像 u-boot 有一段 重定位的操作，经过重定位后， VS Code gdb 就无法正常加人断点了，也就是没有了调试符号与信息，这部分后续再梳理一下。
- 当前的 VS Code gdb 界面源码调试 u-boot，可以从
reset开始，单步【F11】配合【F10】与 手动断点，了解 u-boot 的第一阶段的启动流程，感觉对熟悉 u-boot 启动流程 还是有点用处。
小结
- VS Code GDB 调试功能，感觉有点像专业的 Visual Studio 的感觉了，嵌入式软件可以调试，这本身就是一件好事，利于熟悉代码执行流程、问题定位等。
- 调试过程中，有寄存器、局部变量、断点、【监视】watch 等窗口，可以观察程序执行的当前状态，很有用，至少比 gdb【命令行】调试起来舒服与高效