前言
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办法有局限，不实用轻量级零碎、小型零碎和一次启动的规范零碎。