共计 1394 个字符，预计需要花费 4 分钟才能阅读完成。
前言
OpenAtom OpenHarmony（简称“OpenHarmony”）适配新的开发板时，启动流程 init 大概率会呈现问题，其为内核间接拉起的第一个用户态过程，问题定位伎俩只能依赖代码走读和减少调试打印，初始化过程中零碎解体的问题就更难定位了。如果能应用 gdb 调试 init，会极大进步定位效率。本文将具体阐释二次启动的规范零碎如何应用 gdb 调试 init。
1． 编译出带 debug 信息的调试版本
将 gdb 打包到零碎镜像中。init 不失常的状况下，零碎无奈失常启动工作，无奈应用 hdc 工具加载 gdb 工具，所以间接在制作镜像时，将其打包到零碎镜像 bin 目录下。批改 device\board\hihope\rk3568\cfg\BUILD.gn 打包脚本如下，留神保障 gdb 工具已搁置在此本目录下。
- 调试版本镜像带符号，须要批改镜像配置文件，批改其大小限度，尤其是 system.img，编译失败时不会提醒理论镜像大小，须要批改到 5G 以上。
- 编译调试版本，关上版本调试开关
./build.sh –product-name=XXX –gn-args=”is_debug=true use_unstripped_as_runtime_outputs=true”
上述 debug 版本只能调试一般性能而不能调试 init，还须要对 init 服务的源码进行局部适配批改，init 性能调试失常后，需将源码复原。
首先，在 init 挂载好 system、vendor 等镜像，并将根目录切换到 system 镜像后，在启动第二阶段 init 时，切换到 shell 下，进行 init 初始化流程，见下图 B 处。源码详见 base\startup\init\ services\init\standard\init.c。
留神：A 处的 CloseStdio() 须要正文掉。
思考用 gdb 启动 init 第二阶段，init 绝大部分解决流程都在这一阶段，从这里开始就能够用 gdb 调试了，init 第一阶段解决相对而言流程简略一些，代码走读和调试打印根本就能解决问题。
在 init 主函数中去掉“不等于过程 1 就返回的解决”，因为用 gdb 起 init 第二阶段时，其过程非 1。源码详见 base\startup\init\services\init\main.c。
init 过程中不初始化 Paramworkspace，后面 pid= 1 的判断，在 gdb 调试 init 时条件不成立，所以此处减少判断 init 名就间接退出的解决。源码详见 base\startup\init\services\param\base\param_base.c。
做好了上述筹备，就能够用 gdb 调试 init：
把系统启动，革新后的 init 初始化第一阶段实现后，会停在 shell 下，此时应用下述命令启动 init 第二阶段：
gdb –args /bin/init –second-stage
为了调试 init 的子过程，还须要 gdb 下述命令
set follow-fork-mode child
总结
本文章针对 OpenHarmony 零碎在调试 init 初始化流程时，短少高效的问题定位伎俩这一痛点，引入了嵌入式零碎开发的支流调试工具——gdb，详细描述了这一办法波及到的版本编译、适配点批改以及调试命令操作等细节解决，领导开发者进步定位 init 问题的效率。
须要留神，以后 gdb 调试 init 办法有局限，不实用轻量级零碎、小型零碎和一次启动的规范零碎。
