一、ELF

Executable and linking format(ELF)文件是x86Linux系統(tǒng)下的一種常用目標文件(object file)格式，有三種主要類型：

???????? (1)適于連接的可重定位文件(relocatable file)，可與其它目標文件一起創(chuàng)建可執(zhí)行文件和共享目標文件。?
???????? (2)適于執(zhí)行的可執(zhí)行文件(executable file)，用于提供程序的進程映像，加載的內存執(zhí)行。?
???????? (3)共享目標文件(shared object file)，連接器可將它與其它可重定位文件和共享目標文件連接成其它的目標文件，動態(tài)連接器又可將它與可執(zhí)行文件和其它共享目標文件結合起來創(chuàng)建一個進程映像。?
ELF文件格式比較復雜。

二、HEX

Intel HEX文件是記錄文本行的ASCII文本文件，在Intel HEX文件中，每一行是一個HEX記錄，由十六進制數(shù)組成的機器碼或者數(shù)據(jù)常量，Intel HEX文件經常被用于將程序或數(shù)據(jù)傳輸?
存儲到ROM、EPROM，大多數(shù)編程器和模擬器使用Intel HEX文件。?
???????? 記錄格式?
???????? 一個Intel HEX文件可以包含任意多的十六進制記錄，每條記錄有五個域，下面是一個記錄的格式。?
: llaaaatt[dd。。。]cc?
???????? 每一組字母是獨立的一域，每一個字母是一個十六進制數(shù)字，每一域至少由兩個十六進制數(shù)字組成，下面是字節(jié)的描述。?
???????? : 冒號 是每一條Intel HEX記錄的開始?
???????? ll 是這條記錄的長度域，他表示數(shù)據(jù)(dd)的字節(jié)數(shù)目。?
???????? aaaa 是地址域，他表示數(shù)據(jù)的起始地址?
???????? tt 這個域表示這條HEX記錄的類型，他有可能是下面這幾種類型?
???????? 00 —-數(shù)據(jù)記錄?
???????? 01 —-文件結束記錄?
???????? 02 —-擴展段地址記錄?
???????? 04 —-擴展線性地址記錄?
???????? dd 是數(shù)據(jù)域，表示一個字節(jié)的數(shù)據(jù)，一個記錄可能有多個數(shù)據(jù)字節(jié)，字節(jié)數(shù)目可以?
查看ll域的說明
???????? cc 是效驗和域，表示記錄的效驗和，計算方法是將本條記錄冒號開始的所有字母對
所表示的十六進制數(shù)字?
???????? 都加起來然后模除256得到的余數(shù)最后求出余數(shù)的補碼即是本效驗字節(jié)cc。?
???????? : 0300000002005E9D?
???????? cc=0×01+NOT((0×03+0×00+0×00+0×00+0×02+0×00+0×5E)%0×100)=0×01+0×9C=0×9D >?
???????? 數(shù)據(jù)記錄?
???????? Intel HEX文件由若干個數(shù)據(jù)記錄組成，一個數(shù)據(jù)記錄以一個回車和一個換行結束?
比如下面的一條數(shù)據(jù)記錄?
???????? : 10246200464C5549442050524F46494C4500464C33?
???????? 10 是此行記錄數(shù)據(jù)的字節(jié)數(shù)目?
???????? 2462 是數(shù)據(jù)在內存中的起始地址?
???????? 00 是記錄類型00(是一個數(shù)據(jù)記錄)?
???????? 464C 到 464C 是數(shù)據(jù)?
???????? 33 是此行記錄的效驗和?

三、BIN
BIN文件就是直接的二進制文件，內部沒有地址標記。一般用編程器燒寫時從00開始，而如果下載運行，則下載到編譯時的地址即可。

總結：可以由ELF文件轉化為其它兩種文件，HEX也可以直接轉換為BIN文件，但是BIN要轉化為HEX文件必須要給定一個基地址。而HEX和BIN不能轉化為elf文件，因為ELF的信息量要大。另外還有一種ads的調試文件axf，
它可以轉化為BIN文件，用以下命令 fromelf -nodebug xx。axf -bin xx。bin即可。

這里所說的ARM系統(tǒng)基本文件格式，都是在基于ARM的嵌入式系統(tǒng)開發(fā)中常會碰到的文件格式。
????ARM系統(tǒng)基本文件格式有三種：
1)?BIN，平板式二進制格式，一般用于直接燒寫到Flash中，也可以用于加載到monitor程序中。
2)?ELF，EXECUTABLE?AND?LINKABLE?FORMAT，一種通用的OBJECT文件格式，一般由GNU?COMPILER?COLLECTION?(GCC)產生。
3)?AXF，BIN格式的擴展版,主體部分同BIN，在文件頭和尾加入了調試用的信息，用于AXD。
????本文主要討論BIN與ELF。
????首先說明，ELF格式是一種OBJECT文件格式。一般OBJECT文件都可以分成三類：可重定位OBJECT文件，可執(zhí)行OBJECT文件，共享OBJECT文件。ELF格式文件也可以分成這三種。
????首先說說可重定位OBJECT文件。這種OBJECT文件一般由GCC中的ASSEMBLER(as)產生(請不要認為GCC只是編譯器)，里面除了二進制的機器代碼，還有一些可用于進行重定位的信息。它主要是作為LINKER(ld)的輸入，LINKER將跟據(jù)這些信息，將需要重定位的符號重定位，進而產生可執(zhí)行的OBJECT文件。ELF格式的可重定位OBJECT文件由header與section組成。
????Header?包括ELF?header?與?section?header.?ELF?header?位于文件的頭部，用于存儲目標機器的架構，大小端配置，ELF?header大小，object文件類型，section?header?在文件中的偏移，section?header????的大小，section?header?中的項目數(shù)等信息。Section?header?則定義了文件中每個section?的類型，位置，大小等信息。Linker就是通過查找ELF?header，找到section?header?的入口，再在section?header?中找到相應的section?入口，進而定位到目標section?的。
? ??Section?包括?

.text????：經過編譯的機器代碼。
.rodata??：只讀的數(shù)據(jù)，例如printf(“hello!”)中的字符串hello。
.data????：已初始化的全局變量，局部變量將在運行時被存放在堆棧中，不會在.data或?.bss段中出現(xiàn)。
.bss?????：未初始化的全局變量，在這里只是一個占位符，在object文件中并沒有實際的存儲空間。
.symtab??：符號表，用于存放程序中被定義的或被引用到的全局變量和函數(shù)的信息。
.rel.text??：一個保存著一系列在.text中的位置的列表。這些位置將在linker把這個文件與其它object文件合并時被修改，一般來說，這些位置都是保存著一些引用到全局變量或者外部函數(shù)的指令。引用局部變量或者本地函數(shù)的指令是不需要被修改的，因為局部變量和本地函數(shù)的地址一般都是使用PC相對偏移地址的。需要注意的是，這個section?和下面的.rel.data在運行時并不需要，生成可執(zhí)行的ELF?object文件時會去掉這個section。
.rel.data?：保存全局變量的重定位信息。一般來說，如果一個全局變量它的初始化值是另一個全局變量的地址，或者是外部函數(shù)的地址，那么它就需要被重定位。
.debug??：保存debug信息。
.strtab??：?一個字符串表，保存著.symtab和.debug?,和各個section的名字。.symtab，.debug?和section?table里面，凡是保存name的域，其實都是保存了一個偏移值，通過這個偏移值在這個字符串表里面可以找到相應得字符串。

?下面仔細討論一下.symtab：

每一個可重定位的object文件，都會有一個.symtab。這個符號表保存了在這個object文件中所有被定義的和被引用的符號。當源程序是C?語言程序時，.symtab?中的符號直接來源于C編譯器(cc1)。這里所說的符號主要有三種：
1)?在這個object文件中被定義的可以被其他object文件全局符號。在C語言源程序中，主要就是那些非靜態(tài)（沒有static?修飾的）的全局變量和非靜態(tài)的函數(shù)。在ARM匯編語言中，就是那些?被EXPORT?指令導出的變量。
2)?在這個object文件中引用到，但是在其他文件中定義的全局變量。在ARM匯編語言中就是通過IMPORT命令引入的變量
3)?本地變量。本地變量只在本object文件內可見。這里的本地變量指的是連接器本地變量，應該和一般的程序本地變量作區(qū)別。這里所指的本地變量，包括用static?修飾的全局變量，object文件中section名稱，源代碼文件名稱。一般意義上的本地變量，是在運行時由系統(tǒng)的運行時環(huán)境管理的，linker并不關心。
????每個符合上面條件的符號在.symtab文件中都會有一個數(shù)據(jù)項。這個數(shù)據(jù)項的數(shù)據(jù)結構是：

Typedef?struct{
????int?name;//符號名稱，其實就是.strtab的偏移值
????int?value;//在section中的位置，以相對section地址的偏移表示
????int?size;//大小
????char?type;//類型，一般是數(shù)據(jù)或函數(shù)
????char?binding;//是本地變量還是全局變量
????char?reserved;//保留的位
????????char?section;//符號所屬的section?？蛇x有：.text(用數(shù)字1代表)，.data(用數(shù)
????????????????????????????//3代表)，ABS（不應被重定位的符號），UND（在本object文件
????????????????????????????//中未定義的符號，可能在別的文件中定義），COM（一般的未初//始化的變量符號）。
}ELF_sym

?現(xiàn)在假設組成應用的各個模塊都已經被匯編，構建出了可重定位的object文件。這些object的結構都是一樣的，有各自的.text,?.data?section,?有各自的.symtab.?GCC下一步要做的就是使用linker?(ld),把這些object文件，加上必要的庫連接成具有絕對運行時地址的可執(zhí)行文件，就是可執(zhí)行的ELF格式的文件。
? ??Linker?的連接動作可以分為兩部分：

1)?符號解析。確定引用符號的指向。
2)?符號重定位。合并section,????分配運行時環(huán)境地址，引用符號重定位。
????符號解析：
????在一個object文件中，有指令定義了符號，也有指令引用了符號?？赡艽嬖谶@樣一種情況，一個被引用到的符號，有多重的定義。符號解析的作用就是確定，在這個object文件中，一個符號引用真正引用的是哪個符號。
????在編譯的時候，除了在本文件中定義的全局變量會由編譯器生成一個符號表項之外，當發(fā)現(xiàn)一個被引用到的符號在本文件中并沒有被定義，編譯器也會自動產生一個符號表項，把確定這些引用的工作留給linker。匯編器在匯編時將讀取這些符號表項，生成.symtab。在讀取的過程中，如果發(fā)現(xiàn)有在無法確定的符號引用項，匯編器會為這些符號額外生成一個數(shù)據(jù)項，稱作重定位數(shù)據(jù)項，存放于rel.text或rel.data?section中，交由linker確定。下面是重定位數(shù)據(jù)項（relocation?entry）的數(shù)據(jù)結構：

Typedef?struct{
????int?offset;//指明需要被重定位的引用在object中的偏移，實際上就是需要被重定位的引用
???????????????????//在object中的實際位置
????int?symbol;//這個被重定位的引用真實指向的符號
????int?type;//重定位類型：R_ARM_PC24:使用24bit的PC相對地址重定位引用
??????????//R_ARM_ABS32:使用32bit絕對地址重定位引用
}Elf32_Rel

Linker?需要解析的，就是那些被生成了重定位數(shù)據(jù)項的引用。Linker將根據(jù)C語言定義的規(guī)則，對于每一個重定位數(shù)據(jù)項，在輸入的各個object文件中查找適合的符號，把這個符號填入symbol項中。但是由于還不知道這個符號的真實地址，所以現(xiàn)在就算知道了引用的真實指向，但我們還是不能確定這個引用指向的地址。

符號重定位：
????符號重定位用來解決上面的問題。Linker首先進行section?的合并。Linker合并object文件的過程很簡單，一般就是相同屬性的section合并，例如不同object文件的.text?section?將被合并成一個.text。同樣，.symtab?section也被合并成一個.symtab。這里面涉及到兩個問題：
1)?各個object文件合并的順序。這個問題涉及到最終指令和符號的運行地址。最為重要的是，究竟是哪個section排在最前頭？在ARM?RAW?系統(tǒng)得開發(fā)過程中，這個最為重要。ARM系統(tǒng)CPU上電后，系統(tǒng)會自動的從0x00000000地址取指令并執(zhí)行，這個地址上映射著存儲器。這個動作是不可編程的。所以排在最前面的section一定要包含有程序的入口點，否則系統(tǒng)無法正常運行。
2)?輸入段與輸出端之間的對應關系。理論上，任何section,都可以被隨意的映射到一個輸出段中。一個.data?section是可以與一個.text?section?組成輸出一個.text的。當然這樣的動作毫無意義。我們必須告訴linker使用那些section作為輸入，產生一個輸出section.
????以上這兩個問題，都是通過一個稱為連接腳本的文件控制的。Linker通過讀取連接腳本，來決定section?從輸入到輸出的映射，設置程序的入口點，設置哪個section應該在整個可執(zhí)行文件的頭部等問題。
????連接腳本還有另外一個作用，那就是指定每個section的地址。在section?合并完成后，linker將跟據(jù).symtab，對符號進行統(tǒng)一的編址，分配一個絕對的運行時地址。這個地址是以section地址作為基地址的。假設.text?section的地址是0x00000000，那么.text里面的符號將以0x00000000這個地址作為基準地址。指定section地址的工作也是由連接腳本完成。在嵌入式開發(fā)中常見的在編譯工程時需指定的text_base,?data_base等參數(shù)，最后會被加入到連接腳本中，從而完成section的地址分配。
????以上兩步完成后，linker?執(zhí)行引用符號重定位操作。Linker遍歷.rel?section?(包括.rel?text?和?.rel?data)，對于其中的每個數(shù)據(jù)項，根據(jù)symbol域到.symtab?中查出相應的引用的真實地址(經過上面的地址分配，現(xiàn)在.symtab里面的符號都具有絕對的運行地址)，再根據(jù)offset域提供的偏移，將這個地址填入相應的位置上。
????至此，符號重定位工作全部完成。Linker刪除用于保存重定位信息的rel.text和rel.data?section，加入一個segment?header和?一個.init?section。生成可執(zhí)行的ELF格式的object文件。
????Segment?header保存了用于操作系統(tǒng)內存映射的信息。.init?section?包含了一個_init?的函數(shù)。程序加載時，操作系統(tǒng)的程序加載器通過讀取segment?header，將程序加載到用戶內存空間，并根據(jù)segment?header里面映射信息，分別將.text?段和.data段映射到適當?shù)牡刂飞?。然后再調用.init中的_init函數(shù)，完成初始化工作。
????由于ELF文件具有通用性強的優(yōu)點，現(xiàn)在流行的開發(fā)模式是，先通過編譯工具生成ELF文件格式的可執(zhí)行文件，在使用外部工具，抽離出ELF文件中的相應部分，生成BIN文件。例如著名的GNU?bootloader?U-Boot，就采用了這種做法，編譯器工具集是GCC，BIN生成工具是elf2bin。ARM公司著名的開發(fā)環(huán)境ADS，雖然使用的是自家的armcc,和armcpp編譯器，但他們的工作方式卻是與GNU?GCC如出一轍。

??