OpenHarmony 適配新的開發(fā)板時，啟動流程 init 大概率會出現(xiàn)問題。

其為內(nèi)核直接拉起的第一個用戶態(tài)進(jìn)程，問題定位手段只能依賴代碼走讀和增加調(diào)試打印，初始化過程中系統(tǒng)崩潰的問題就更難定位了。如果能使用 gdb 調(diào)試 init，會極大提高定位效率。

本文將詳細(xì)闡釋二次啟動的標(biāo)準(zhǔn)系統(tǒng)如何使用 gdb 調(diào)試 init。

用 gdb 調(diào)試 init

①編譯出帶 debug 信息的調(diào)試版本

將 gdb 打包到系統(tǒng)鏡像中。init 不正常的情況下，系統(tǒng)無法正常啟動工作，無法使用 hdc 工具加載 gdb 工具，所以直接在制作鏡像時，將其打包到系統(tǒng)鏡像 bin 目錄下。

修改 deviceoardhihope k3568cfgBUILD.gn 打包腳本如下，注意保證 gdb 工具已放置在此本目錄下。

②調(diào)試版本鏡像帶符號

需要修改鏡像配置文件，修改其大小限制，尤其是 system.img，編譯失敗時不會提示實際鏡像大小，需要修改到 5G 以上。

③編譯調(diào)試版本，打開版本調(diào)試開關(guān)

./build.sh--product-name=XXX--gn-args="is_debug=trueuse_unstripped_as_runtime_outputs=true"

上述 debug 版本只能調(diào)試普通功能而不能調(diào)試 init，還需要對 init 服務(wù)的源碼進(jìn)行部分適配修改，init 功能調(diào)試正常后，需將源碼恢復(fù)。

首先，在 init 掛載好 system、vendor 等鏡像，并將根目錄切換到 system 鏡像后。

在啟動第二階段 init 時，切換到 shell 下，停止 init 初始化流程，見下圖 B 處。

源碼詳見 basestartupinit servicesinitstandardinit.c。注意：A 處的 CloseStdio() 需要注釋掉。

考慮用 gdb 啟動 init 第二階段，init 絕大部分處理流程都在這一階段，從這里開始就可以用 gdb 調(diào)試了，init 第一階段處理相對而言流程簡單一些，代碼走讀和調(diào)試打印基本就能解決問題。

在 init 主函數(shù)中去掉“不等于進(jìn)程 1 就返回的處理”，因為用 gdb 起 init 第二階段時，其進(jìn)程非 1。

源碼詳見basestartupinitservicesinitmain.c。

init 進(jìn)程中不初始化 Paramworkspace，前面 pid=1 的判斷，在 gdb 調(diào)試 init 時條件不成立，所以此處增加判斷 init 名就直接退出的處理。

源碼詳見 basestartupinitservicesparamaseparam_base.c。

做好了上述準(zhǔn)備，就可以用 gdb 調(diào)試 init。

把系統(tǒng)啟動，改造后的 init 初始化第一階段完成后，會停在 shell 下，此時使用下述命令啟動 init 第二階段。

gdb--args/bin/init--second-stage為了調(diào)試 init 的子進(jìn)程，還需要 gdb 下述命令：setfollow-fork-modechild

總結(jié)

本文章針對 OpenHarmony 系統(tǒng)在調(diào)試 init 初始化流程時，缺少高效的問題定位手段這一痛點，引入了嵌入式系統(tǒng)開發(fā)的主流調(diào)試工具——gdb，詳細(xì)描述了這一方法涉及到的版本編譯、適配點修改以及調(diào)試命令操作等細(xì)節(jié)處理，指導(dǎo)開發(fā)者提高定位init問題的效率。

需要注意，當(dāng)前 gdb 調(diào)試 init 方法有局限，不適用輕量級系統(tǒng)、小型系統(tǒng)和一次啟動的標(biāo)準(zhǔn)系統(tǒng)。
審核編輯：陳陳