使用gdb
跟蹤除錯核心從
start_kernel
到init
程序啟動
使用gdb
跟蹤除錯核心 開啟
shell
終端，執行以下命令：
cdlinuxkernel/
qemu -kernellinux-3.18.6/arch/x86/boot/bzimage-initrd rootfs.img -s -s 關於
-s和-s選項的說明：
-s freeze cpuat startup (use 』c』 to start execution)
在系統啟動的時候凍結
cpu，使用
c鍵繼續執行後續操作
-s shorthandfor -gdb tcp::1234
開啟遠端除錯埠，預設使用
tcp協議
1234
埠，若不想使用
1234
埠，則可以使用
-gdb tcp:***x
來取代-s選項
函式即是
linux
核心啟動過程由平台相關轉為平台無關**後第乙個執行的函式，在這個函式中，
linux
核心開始真正進入初始化階段。
trap_init()
中斷向量表的初始化函式，設定了很多中斷門
(interrupt gate)
，其中設定了後面會關注到的
system_call
sched_init()
程序排程初始化函式，函式內做了很關鍵的一步初始化——對
0號程序，即
idle
程序進行初始化
rest_init()
其他初始化函式，函式內將建立
1號程序，即
init
程序。下面主要來分析該函式。
從rest_init開始，linux開始產生程序，因為init_task是靜態製造出來的，pid=0，它試圖將從最早的彙編**一直到start_kernel的執行都納入到init_task程序上下文中。在rest_init函式中，核心將通過下面的**產生第乙個真正的程序(pid=1):
static noinline void __init_refok rest_init(void)
函式的末尾，
0號程序
idle就在
cpu_startup_entry
事實上在更早前的sched_init（）函式中，通過init_idle(current, smp_processor_id())函式的呼叫就已經把init_task初始化成了乙個idle task，init_idle函式的第乙個引數current就是&init_task，在init_idle中將會把init_task加入到cpu的執行佇列中，這樣當執行佇列中沒有別的就緒程序時，init_task（也就是idle task)將會被呼叫，它的核心是乙個while(1)迴圈，在迴圈中它將會呼叫schedule函式以便在執行佇列中有新程序加入時切換到該新程序上。
Linux核心分析 實驗二
該實驗要求完成乙個簡單的時間片輪轉多道程式核心 首先我們看看mykernel裡面的mypcb.h define max task num 10 max num of task in system define kernel stack size 1024 8struct thread typedef...
Linux核心分析 實驗四
當我們使用某些庫函式的api時，實際上該庫函式啥都沒乾，它只是乙個系統呼叫的封裝。x86為例，系統呼叫會執行int 0x80指令，也就是陷入。作業系統會變為核心態，查詢系統呼叫表，跳轉到相應的系統呼叫。每個系統呼叫都對應乙個唯一的系統呼叫號，系統呼叫之前，會從eax暫存器讀系統呼叫號，系統呼叫的返回...
實驗三 跟蹤分析Linux核心的啟動過程
linux核心分析 mooc課程 一 linux核心原始碼 arch目錄下儲存有各個平台的源 fs檔案系統linux核心的原始碼放在kernel目錄中。原始碼的目錄結構如下圖所示 二 乙個簡單的linux系統menuos 三 使用gdb跟蹤除錯linux核心的方法 s freeze cpu at s...