在使用Linux时，总是会遇到一些意想不到的困难。而且似乎无穷无尽。这里打算写一个笔记，以后逐步来完善。特别是：调试的技能，总是占程序员的主要部分。在设置可视化调试环境过程中，常会同样陷入困境，有时深感自己资质愚钝。
下面的问题，尽管网上会有许多方案，但我只会记录自己尝试发现有用的一种。并且描述其中的坑。
目录
sudo qemu-system-arm -M vexpress-a9 -m 256 -kernel ./u-boot -nographic -s -S手工调试
编译和启动Qemu
VsCode的 sudo问题。
Why:要sudo不输入密码
VsCode调试时，python插件，的确有能力，接受sudo的同时，也输入用户名和密码。
但非常不幸的是，C++插件并没有这个能力。
如果你需要用root来启动Vscode，也是可以的，需要将配置的目录告诉它，总之很难使用，所以不这一段的话题，以后有机会再来描述，哪些时候用得着。比如，调试bash shell的时候。
What和场景
场景因为，C++插件不支持sudo输入密码的问题。
即应用场景是：ubuntu+非root普通用户启动vscode，但是需要sudo启对被调试对象的情况。
所以，实现的要求是（what）：要求操作系统，对当前用户， sudo时不需要输入密码。
【解决】，这个问题的答案在网上很多，例如：Linux设置sudo无需密码【Ubuntu、多种方法】_linux设置sudo免密-CSDN博客
之所以要写出来，是因为我在操作时，漏看了一句话：
放在最后面。
具体：
1.修改visudo
sudo visudo
2.添加用户名权限
进入页面后可使用ctrl + end下滑至底部
添加以下命令，xxx为你的用户名
xxx ALL=(ALL) NOPASSWD: ALL
这里的问题是我没有看到这句话：
进入页面后可使用ctrl + end下滑至底部
所以，写在了中间。结果就没有生效！
【坑】要写在最后！
编译u-boot过程
sudo apt-get install build-essential pkg-config zlib1g-dev libglib2.0-0 libglib2.0-dev libsdl1.2-dev libpixman-1-dev libfdt-dev autoconf automake libtool librbd-dev libaio-dev flex bison -y
sudo apt-get install gcc-arm-linux-gnueabihf
#交叉编译链 安装
sudo apt-get install gcc-arm-linux-gnueabihf
sudo apt-get install g++-arm-linux-gnueabihfsudo apt install qemu-system-arm
qemu-system-arm -M help
git clone https://gitlab.denx.de/u-boot/u-boot
sudo make vexpress_ca9x4_defconfig ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
make clean && make vexpress_ca9x4_defconfig
make -j$(nproc)
【坑】这个过程，其实坑也不少。最困难是
/usr/bin/arm-none-eabi-gdb
并不容易被装上。这个以后我再补充，有两种方案，一种是自己下2019 q4源码包，编译；
另一种是装gdb-multi，然后软链接。均可。
利用qemu启动u-boot
sudo qemu-system-arm -M vexpress-a9 -m 256 -kernel ./u-boot -nographic
必须要用sudo。
如果需要单步跟踪，需要启动qemu自带gdbserver, 作为stub
sudo qemu-system-arm -M vexpress-a9 -m 256 -kernel ./u-boot -nographic -s -S
第一个小s是启动gdbserver on port :1234 ; 大S是表示启动后，自动停止qemu（qemu在这里相当于CPU）。
单步模式，如果正常启动，程序不会有任何输出。
必须要用sudo。如果不用root权限，则可能会报声卡无法加载的错误。
尽管，网上有方案，认为qemu可以不用root权限启动，但我没有试成功。
【坑】一定要用sudo
如何kill 进程by name
ps -ef | grep qemu | grep -v grep | awk '{print $2}' | xargs sudo kill -9
如何利用vscode进行调试
简要说明：我们的目标，在是一台windows10的机器上，远程跟踪ubuntu上的u-boot程序。
这里我们先剧透一下：第一步是在ubuntu进行单机的qemu调试（实际是双机：实机+Qeum,连接by gdb stub）；第二步是在远程，通过SSH进行调试。
为什么说剧透呢？因为习惯了gdbclient + gdb stub +gdb server思维模式后，这里需要转个弯。因为vscode并没有用这种模式，进行三机调试，而是在ubuntu上，装了一个Remote vscode server.
这是一种新认知。而且还不错。这种创新，带来一些意想不到的问题和方便。
如何手工GDB调试
启动qemu
sudo qemu-system-arm -M vexpress-a9 -m 256 -kernel ./u-boot -nographic -s -S
手工调试
arm-none-eabi-gdb u-boot
target remote localhost:1234
先启动gdb，然后等gdb的输出，出现后，再输入：target remote localhost:1234
注意：都要在工作目录执行，即u-boot所在的目录。
另外，应先安装gcc-arm-none-eabi。
sudo apt install gcc-arm-none-eabi gdb-multiarch
如果装上，还是没有，要么下代码自己编译，要么将软链接到/usr/bin/arm-none-eabi-gdb
在ubuntu调试
如前所述，windows三机调试（win-->ubuntu-->qemu）的模式，被vscode简化来类似远程桌面一样的架构，也就是说，只要配置好ubuntu 的debug环境，即能够实现远程调试。
所以，目前最重要的要点，就是如何配置launch.json
我们这里尽量暂时不上图了，以后补上，因为这方面的信息，网上很多。我们只把lanch.json 的内容放在这里：
{
"version": "0.2.0",
"configurations": [
{
"name": "uboot-debug",
"type": "cppdbg",
"request": "launch",
"miDebuggerServerAddress": "127.0.0.1:1234",
"miDebuggerPath": "/usr/bin/arm-none-eabi-gdb",
"program": "${workspaceFolder}/u-boot",
"args": [],
"stopAtEntry": true,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"logging": {
"engineLogging": false
},
"MIMode": "gdb"
}
]
}
https://www.jb51.net/program/2903513gi.htm虽然这里每一句都很重要，但最明显的是：
"miDebuggerServerAddress": "127.0.0.1:1234",
1234是qemu以-s参数启动时，开的gdb server的占用的端口。
然后我们手工启动qemu:
sudo qemu-system-arm -M vexpress-a9 -m 256 -kernel ./u-boot -nographic -s -S
就可以F5调试了。利用gdb命令行的方式的调试，以后补上。
