OpenHarmony系统如何使用gdb调试init

OpenHarmony 适配新的开发板时，启动流程 init 大概率会出现问题。

其为内核直接拉起的第一个用户态进程，问题定位手段只能依赖代码走读和增加调试打印，初始化过程中系统崩溃的问题就更难定位了。如果能使用 gdb 调试 init，会极大提高定位效率。

本文将详细阐释二次启动的标准系统如何使用 gdb 调试 init。

用 gdb 调试 init

①编译出带 debug 信息的调试版本

将 gdb 打包到系统镜像中。init 不正常的情况下，系统无法正常启动工作，无法使用 hdc 工具加载 gdb 工具，所以直接在制作镜像时，将其打包到系统镜像 bin 目录下。

修改 deviceoardhihope k3568cfgBUILD.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 处。

源码详见 basestartupinit servicesinitstandardinit.c。注意：A 处的 CloseStdio() 需要注释掉。

考虑用 gdb 启动 init 第二阶段，init 绝大部分处理流程都在这一阶段，从这里开始就可以用 gdb 调试了，init 第一阶段处理相对而言流程简单一些，代码走读和调试打印基本就能解决问题。

在 init 主函数中去掉“不等于进程 1 就返回的处理”，因为用 gdb 起 init 第二阶段时，其进程非 1。

源码详见basestartupinitservicesinitmain.c。

init 进程中不初始化 Paramworkspace，前面 pid=1 的判断，在 gdb 调试 init 时条件不成立，所以此处增加判断 init 名就直接退出的处理。

源码详见 basestartupinitservicesparamaseparam_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 方法有局限，不适用轻量级系统、小型系统和一次启动的标准系统。
审核编辑：陈陈