其为内核直接拉起的第一个用户态进程，问题定位手段只能依赖代码走读和增加调试打印，初始化过程中系统崩溃的问题就更难定位了。如果能利用 gdb 调试 init，会极大提高定位效率。
本文将详细阐释二次启动的标准系统如何利用 gdb 调试 init。
用 gdb 调试 init
①编译出带 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 方法有局限，不适用轻量级系统、小型系统和一次启动的标准系统。
