這些技巧都是平時我自已在閱讀的時候總結的,想到哪就說到哪了,其實我總結的技巧遠不止這些,但是先說這些吧。後面想到了再補充,只有在拿到代碼做分析的時候遇到實際的問題時,才能見招拆招,想些辦法。
其實linux核心源碼還是比較難跟蹤的,我剛開始閱讀核心源碼的時候,感覺很多東西經常找著找著就失去頭緒了,很鬱悶。
通過一些閱讀後發現核心也就那麼幾招用的比較多,摸清楚其脾氣後,剩下的就是耐心了。
1.我曾經用過一陣VI,裝了一堆外掛程式後折騰了一陣,發現還是無法感受其推崇者所說的那一堆好處,還是喜歡用sourceinsight。好了,說正題了。首先我們要解決的就是函數或者變數找不到定義地方的問題,表現在sourceinsight上就是那個變數是黑的,到處找不到。
比如我們看們看到:
int bus_register(struct bus_type * bus)
{
...
subsys_set_kset(bus, bus_subsys);
retval = subsystem_register(&bus->subsys);
...
}
其中的bus_subsys。
找了一下bus_subsys找不到定義的地方,肯定是核心和我們躲貓貓,這時候我們可以是否尋找一些明顯的“定義痕迹”,比如在bus_subsys中的subsys或者說_subsys。果然有新發現。我們找到了這麼一個宏。
#define decl_subsys(_name,_type,_uevent_ops) /
struct subsystem _name##_subsys = { /
.kset = { /
.kobj = { .name = __stringify(_name) }, /
.ktype = _type, /
.uevent_ops =_uevent_ops, /
} /
}
得,我們回過頭在包含有bus_register的源檔案及標頭檔中尋找一下,果然找到了static decl_subsys(bus, &ktype_bus, NULL);這麼一行代碼。
像這種東西我不是很建議一找不到就直接去網上找,關於核心的文章網上雖然很多,但都不會細到所有的細節都有,你總有獨立處理問題的時候,為什麼我們不提前讓自已多鍛煉一下呢?
2.順序問題,核心有很多的順序,比如初始化的順序,比如我們有module_init,__initcall等等,一來編譯的時候檔案夾和檔案有順序,另外不同的宏包含的東西順序也是有講究的,所以在分析模組的時候一定要注意這個,這個東西只能說是注意了,如果對一個模組不熟悉的時候,不可能做到全部都瞭解,像我有時候也會落下一些東西忘記分析,但是隨著看核心的時候越久,核心那些慣用的手法見多了後,就發現不外如是,也就那三瓜子兩棗。
3.我們要解決核心運行時那一堆指來指去的指標的問題。這個是我自已調試用的土方法,我就用dump_stack在關鍵的地方列印出順序就行了。因為我們做的是嵌入式裝置,很多時候不能用KGDB這些進階工具線上調,而且這種方法基本不增加其它的效能開銷。
4.有多個定義不知道用哪個。這個基本是因為LINUX支援的CPU比較多造成的。
我們可以用GDB靜態分析,也可以用objdump和nm等工具來精確定位一些函數和變數,也可以根據宏來一步一步分析,比如是mips的那麼我們就進mips看,這樣一步一步來。
5.具備一些意識,你現在面對的是作業系統,不僅僅是只有C檔案和標頭檔的應用,MAKEFILE,連結檔案,Kconfig都應該是你的朋友。尤其在看一個模組或者一小部分你感興趣的代碼的時候,首先可以用MAKEFILE和KCONFIG來縮小你需要關注的範圍。其實關於MAKEFILE和KCONFIG的重要性,fudan_abc在他那個LINUX那些事之我是USB中強調的比較多,但是說實話,fudan_abc那文章看了玩是挺好玩的,可惜感覺好像看了沒啥用,就是知道了一堆概念,不能串起來,我不知道是我的理解能力不行,還是任僑偉同志壓根沒有講清楚。呵呵。