1. Linux下的二進制可執(zhí)行文件。
如果世界很簡單，那么二進制可執(zhí)行文件也應(yīng)該很簡單，只包括CPU要執(zhí)行的指令就可以了?？上?，世界并不簡單……。Linux下的二進制可執(zhí)行文件（以下簡稱可執(zhí)行文件），也并不是只包括了指令，還包括了很多其他的信息，比如，執(zhí)行需要的數(shù)據(jù)，重定位信息，調(diào)試信息，動態(tài)鏈接信息，等等。 所有這些信息都按照一個預(yù)定的格式組織在一個可執(zhí)行文件里面。Linux下叫ELF可執(zhí)行文件。
舉一個最簡單的例子，假設(shè)有下面這個程序：
int main()
{
return 0;
}
這個連“Hello World”都不能打印的程序，自然是什么都做不了。當(dāng)然，如果只是把這個文件保存為文本文件，是無論如何也執(zhí)行不了得。還需要兩個重要的步驟：編譯和鏈接，才能把它轉(zhuǎn)換為可執(zhí)行的ELF格式。
先來看看編譯，也就是把C語言翻譯成機器語言的過程。很簡單，用下面的命令：
gcc -c test.c -o test.o <假設(shè)源文件名為test.c>
-c 參數(shù)告訴gcc，我們只需要編譯這個文件，不需要連接。這樣就會生成一個test.o文件。這個文件包含了上面源程序翻譯后的機器指令和其他一些信息。這個test.o也屬于ELF格式。如何看test.o里面的內(nèi)容，可以用objdump命令：
objdump -x test.o
會有類似下面的輸出：
test.o:fileformatelf32-i386
test.o
architecture:i386,flags0x00000010:
HAS_SYMS
startaddress0x00000000
Sections:
IdxNameSizeVMALMAFileoffAlgn
0.text0000000a0000000000000000000000342**
CONTENTS,ALLOC,LOAD,READONLY,CODE
1.data000000000000000000000000000000402**2
CONTENTS,ALLOC,LOAD,DATA
2.bss000000000000000000000000000000402**2
ALLOC
3.comment0000002b0000000000000000000000402**0
CONTENTS,READONLY
4.note.GNU-stack0000000000000000000000000000006b2**0
CONTENTS,READONLY
SYMBOLTABLE:
00000000ldf*ABS*00000000test.c
00000000ld.text00000000.text
00000000ld.data00000000.data
00000000ld.bss00000000.bss
00000000ld.note.GNU-stack00000000.note.GNU-stack
00000000ld.comment00000000.comment
00000000gF.text0000000amain
test.o 主要包含了文件頭和節(jié)。"節(jié)“是ELF文件的重要組成部分，一個節(jié)就是某一類型的數(shù)據(jù)。objdump的-x參數(shù)會打印出test.o中所有的節(jié)，也就是上面的"Sections". 其中.text節(jié)包含了可執(zhí)行代碼，.data節(jié)包含了已經(jīng)初始化的數(shù)據(jù)，.bss節(jié)包含了未初始化數(shù)據(jù)。其他的節(jié)先忽略掉（其實是因為我也了解不多??）
如果要看看test.o是不是包含源文件的編譯結(jié)果， 可以將其反匯編查看。使用objdump -d 命令。 默認(rèn)情況下，該命令只返回目標(biāo)文件的可執(zhí)行部分，在這里就是.text節(jié)。 objdump -d test.o 得到的結(jié)果如下：
test.o:fileformatelf32-i386
Disassemblyofsection.text:
00000000
0:55push%ebp
1:89e5mov%esp,%ebp
3:b800000000mov$0x0,%eax
8:5dpop%ebp
9:c3ret
可以看見這里就是一些棧的操作，沒有做什么事情。當(dāng)然，源碼里面確實也沒做什么事情。這個.o文件還不能執(zhí)行，還需要經(jīng)過鏈接。通常，我們可以用gcc一步完成編譯鏈接過程，也就是我們最常用的：
gcc test.c -o test
如果再次用objdump -d 反編譯生成的test文件：
objdump -d test
額……會發(fā)現(xiàn)多了一堆東西。這是因為，c程序通常都是鏈接到c運行庫的。在main函數(shù)執(zhí)行前，c運行庫需要初始化一些東西。這也說明，main（）并不是程序的真正入口點。真正的入口點可以用objdump -f 查看test的文件頭：
test:fileformatelf32-i386
architecture:i386,flags0x00000112:
EXEC_P,HAS_SYMS,D_PAGED
startaddress0x080482e0
start address就是開始執(zhí)行的入口點， 這個地址對應(yīng)反匯編中的"_start"符號。
那么可以讓程序不鏈接到c運行庫么？當(dāng)然可以，可以用ld手工鏈接：
ld test.o -e main -o test
“-e main”告訴ld鏈接器用main函數(shù)作為入口點。這里也可以看出，一個程序的入口函數(shù)，不一定是main，可以是任意函數(shù)。再次反匯編剛生成的可執(zhí)行文件，就會發(fā)現(xiàn)，已經(jīng)沒有c運行庫的代碼了。
可是，如果試著執(zhí)行剛剛生成的程序，竟然會得到一個段錯誤……這是因為，沒有了c運行庫，main函數(shù)返回之后，程序執(zhí)行到不確定的地方。而如果通過c運行庫調(diào)用main（），返回后會到c運行庫里面，會調(diào)用相關(guān)函數(shù)來結(jié)束進程。
2. 裸機程序的實現(xiàn)
所謂裸機程序，也就是沒有操作系統(tǒng)支持，芯片上電后就可以開始執(zhí)行的程序，就和單片機程序一樣。不知道用”裸機程序“這個名稱是否合適，不過也找不到其他的名字了。
裸機程序與上面的ELF可執(zhí)行文件有什么不同，首先很明顯一點，ELF文件是需要有一個解析器，或者叫裝載器的， 這個裝載器負(fù)責(zé)解析文件頭，將其中的節(jié)都映射到進程空間，如果有重定位，要先完成重定位，如果有動態(tài)鏈接庫，還要加載動態(tài)鏈接庫，完成種種初始化之后，才跳轉(zhuǎn)到程序的入口點開始執(zhí)行程序。而所有這些，都是由OS支持的。而對于一個ARM芯片來說，他可不知道什么ELF，重定位和動態(tài)鏈接。ARM只知道上電后，寄存器復(fù)位到初始值，PC寄存器為0x00000000,也就是從內(nèi)存地址為0的地方開始取指令執(zhí)行，其它的一概不知道，也不管。
這么說來，要弄出一個裸機程序，其實也不難，只要我們編譯上面的源代碼，然后想辦法把它加載到內(nèi)存0開始的地方就可以了。事實，也確實是這樣。只是有幾個小問題要先解決掉：
1.從0開始的內(nèi)存從哪來？那個地方為什么會有內(nèi)存？
2.如何把程序放到內(nèi)存0開始的地方
3.就算是一個簡單的main（）函數(shù)，也需要棧。誰來負(fù)責(zé)設(shè)置棧？
首先看1，一般ARM芯片都會外接一定數(shù)量的ROM和RAM。而從0開始的地址一般都會映射到ROM上，這樣上電后
下載文檔
