1. 首先設定斷點在start_kernel函式處，使用c命令之後提示進入了該啟動函式，如圖：

圖

2. 進入函式之後發現這裡面的大多數函式並不能從名字上看出它們的意義，只能一步一步的試，於是我在init_task這個重要的程序變數處設定斷點b 510，然後c，發現menuOS竟然開始跑了。但是結果卻不盡如意，因為它最終沒有成功的啟動系統，而是卡死在這一步，於是ctrl+c中斷操作，得到了如下資訊。

default_idle () at arch/x86/kernel/process.c:314
314     trace_cpu_idle_rcuidle(PWR_EVENT_EXIT,，smp_processor_id());
 

於是我去查看了arch/x86/kernel/process.c:314：

310 void default_idle(void)
311 {
312     trace_cpu_idle_rcuidle(1, smp_processor_id());
313     safe_halt();
314     trace_cpu_idle_rcuidle(PWR_EVENT_EXIT,smp_processor_id());
315 }

看完之後一頭霧水，本打算放棄，我看到了在main.c:511中的smp_setup_processor_id()查閱得知，此函式是針對SMP處理器，用於獲取當前CPU的硬體ID，如果不是多核，函式為空。判斷是否定義了CONFIG_SMP，如果定義了，呼叫read_cpuid_mpidr讀取暫存器CPUID_MPIDR的值，即當前正在執行初始化的CPU ID

• 1.檢視/dev/mcelog。在自己的系統上檢視發現這是個c屬性檔案，即字元裝置，查閱得知，該裝置是用於是 x86 的 Linux 系統上用來 檢查硬體錯誤，特別是記憶體和CPU錯誤的工具。
• 2.查閱有關smp_processor_id()的資料，發現這個函式不同於smp_setup_processor_id()函式，它不可以直接讀取暫存器中的值來獲取cpuid，而必須獲取核心變數儲存的處理器id，因此smp_processor_id()
  函式必須使用初始化函式。
  這大概便是為何剛才初始化0程序時出錯的原因了，但是苦於找不到上述兩個函式的原始碼，找到了也不一定能看懂，只能粗略分析至此。

3. 這一次我不再直接進入初始化init_task模組了，在進入start_kernel函式之後，我選擇了b 511，但是這一次c之後，qemu並沒有任何變化。b 512依舊沒有反應，

4.