程序在運行的時候先通過分段(segmentation)的方式將虛擬地址空間與真實的物理內存地址空間進行一一的映射，但是這種方式每次換入換出的是整個程序，導致IO變大，更具局部性原理，可以采用分頁(Paging)來解決. 分頁就是將地址空間人為的等分成固定大小的頁，每頁的大小（4KB或者4MB）由操作系統(tǒng)確定。 幾乎所有操作系統(tǒng)都采用4KB的分頁，那么對于一個32位的程序來說，最多只能有4GB/4KB = 1048576頁， 物理空間也是同樣的分法。但是當真實物理空間不夠虛擬空間的頁數的時候，真正有效的空間以真實內存空間為準。頁的映射是由MMU部件來完成的。MMU一般集成在CPU內部。

外設使用總線地址，CPU使用物理地址。x86平臺上，物理地址和總線地址相同。

線程可以分為IO密集型線程和CPU密集型線程，當CPU密集型線程的優(yōu)先級較高的時候，可能會導致低優(yōu)先級的線程被餓死，而IO密集型線程獲得較高優(yōu)先級的時候，由于大部分時間是處于等待狀態(tài)，所以不叫不容易造成其他線程的餓死。 如果一個線程長時間得不到執(zhí)行，調度系統(tǒng)會逐步提升它的優(yōu)先級讓它執(zhí)行。

線程還可以分為搶占線程和不搶占線程，搶占線程是那些時間片用完之后會被剝奪執(zhí)行權的線程，不可搶占線程是那些除非執(zhí)行完畢否則不能剝奪執(zhí)行權的線程。時至今日，非搶占線程已經十分罕見。

windows對于進程和線程的實現如同教科書一般的標準，但是在linux中其實并沒有嚴格的線程和進程的概念，Linux中所有的執(zhí)行實體都被成為任務Task，每一個任務概念上類似于一個單線程的進程，但是它的不同任務之間可以選擇共享內存空間，因此在實際意義上共享了同一內存空間的多個任務構成了一個進程。

為了保證多線程環(huán)境下操作的原子性，有以下幾種辦法:
6.1 鎖
6.2 二元信號量和多元信號量
6.3 互斥量，和上面兩個的區(qū)別是哪個線程建立的互斥量就必須由哪個線程去釋放
6.4 臨界區(qū)，和上面幾種的區(qū)別是，哪個進程創(chuàng)建臨界區(qū)的鎖，就由哪個進程獲取，對其他進程不可見。
6.5 讀寫鎖，有兩種獲取方式獨占式和共享式，區(qū)別如下

可重入線程是并發(fā)安全的強力保障，一個可重入的函數可以在多線程環(huán)境下放心使用。

三種線程模型
8.1 一對一模型
8.2 多對一模型
8.3 多對多模型

程序編譯運行的流程是 預編譯-編譯-匯編-鏈接， 命令分別是:
gcc -E xx.c -o xx.i
gcc -S xx.i -o xx.s 或者(cc1 xx.i)
gcc -c xx.s -o xx.o 或者(as xx.s -s xx.o)
以及 ld xxx.o xxxx.o xxxx.o等

目標文件即.obj文件或者.o文件,本質上是函數的集合，用于重定位， 他們的內部函數和變量的存儲方式和真正的可執(zhí)行文件一樣只是在結構上稍有不同。

PC流行的PE文件格式和ELF文件格式都是COEF格式的變種。

bss段只是為全局變量和局部靜態(tài)變量預留位置，在elf文件中不占空間。

x86的cpu中字節(jié)序采用小端模式存儲(所以elf文件中變量的存儲采用小端)， arm架構的cpu中采用大端，網絡字節(jié)序(TCP/IP)采用大端傳輸。

elf文件主要包含，代碼段(.text)和數據段(.data, .rodata, .bss), 未初始化的全局變量和和未初始化的局部靜態(tài)變量被存放在.bss段（有時候未初始化的全局變量也會存放在符號表中）。 字符串一般在.rodata段，也有的在.data段。值得一提的是賦值為0的局部靜態(tài)變量也會被認為是未賦值從而放置在bss 段而不是data段。 attribute 命令可以在代碼中指定變量或者函數存放在elf文件的那一段

reaelf -h xx.o可以輸出elf文件的文件頭信息。 ELF文件最開始的16個字節(jié)代表了ELF文件的平臺屬性，其中前四個字節(jié)是ELF文件的魔數，不同平臺的魔術不同(ELF的魔數是0x7f, 0x45, 0x4c, 0x46 即 DEL控制符,‘E’,‘L’,‘F’ PE/COEF的魔數是0x01, 0x07， 即’M’,‘Z’), 操作系統(tǒng)在加載可執(zhí)行文件的時候會確認魔數是否正確，如果不正確會拒絕加載。
第5個字節(jié)是用來標識文件類型，0x01是32位的，0x02是64位的。第6個字節(jié)表示字節(jié)序是大段或者小端，第七個字節(jié)表示ELF的主版本，一般是1。后面9個字節(jié)沒有指定，表示可擴展。

ELF文件中段表的位置由e_shoff成員決定，即(Start of section headers的值決定段表的起始位置)。 readelf -S xx.o 可以顯示真正的段表結構。

elf文件中段表是其中的一個段，段表里面存儲了其他各個段的起始地址和大小還有其他一些信息。

符號表里面存儲了全局變量，全局函數和行號和用于調式和核心轉儲的局部符號，行號等信息，鏈接器在鏈接的時候只關注全局函數和變量。 可重定位文件中包含的局部信息對其他重定位文件來說都是不可見的，只有全局函數和變可見。可以用nm來查看elf文件的符號結果。 符號表也是elf文件中的一個段，段名一般叫做.symtab

readelf -s xx.o可以打印輸出elf包含的符號表的信息。 分別有符號的類型，值(函數或者變量的地址)，大小，綁定信息（局部，全局，弱引用）， Ndx表示符號所在的段的下標，該下標可以通過readelf -a xx.o 看到。 值得注意的是符號表中第一個符號，即下標為0的符號永遠是一個未定義的符號。
對于STT_SECTION類型的符號，它們的符號名沒有顯示，其Ndx所對應的段名也就是這里的符號名， 因為他們是段名符號。可以通過 objdump -t 看到這種段名符號

特殊符號是由ld鏈接器定義的，程序中只需要申明就可以使用，程序在最終鏈接的時候會自動轉化為正確的值，例如__executeable_start, __etext或_etext或etext, _edata或者edata， _end或者end等等。

為了防止函數和全局變量在各文件之間的命名沖突。但是隨著操作系統(tǒng)和編譯器的分化，GCC已經不用在符號前面加_但是windows平臺下的編譯器還保持著前面加_這樣的傳統(tǒng)。此外GCC在windows平臺下下編譯器例如cywin和mingw還保持著這樣的傳統(tǒng)。GCC本身可以通過編譯器選項-fleading-underscore或者-fno-leading-underscore來打開或關閉是否在C語言符號前加下劃線。

函數簽名是C++引入的區(qū)別不同類，命名空間等不同作用域名中相同名稱的成員的機制 binutils提供的 c++filt命令可以解析一個函數修飾后名稱對應的真正的函數簽名。一般規(guī)則是對于在命名空間或者類的中的變量和函數其前面一般是_ZN開頭，以E(+)i/f/d結尾。最后值得說明的是不同平臺的編譯器的對同一函數的函數簽名可能是不同的。 VC++的函數簽名方法沒用向外公開，但是其UndecorateSymbolName()的api可以將修飾后的名稱轉換成函數簽名。
由于不同編譯器采用不同的名字修飾方法，所以導致了不同編譯器產生的目標文件無法正常的相互鏈接，這也是導致不同編譯器之間不能互操作的主要原因之一。
目標文件即OBJ文件是跨平臺的

extern "C"{}語句會導致受作用的變量和函數名在修飾之后采用的是C語言的格式而不是C++. 對于同一個變量或者函數，C++和C語言的修飾不一樣，為了讓C++能正確引用并使用C語言的符號，通常在聲明這個函數的時候會先判斷當前的編譯單元是C還是C++即使用下面的語句

空間地址分配有按序疊加和相似段合并兩種方法，一般都使用相似段合并的方法。最后的可執(zhí)行文件當中包含了可重定位的.o文件里面的所有指令。

Linux下，ELF可執(zhí)行文件默認地址從0x08048000開始分配。生成的可執(zhí)行elf文件中的.text段是各個.o文件的.text段大小之和

elf文件中需要重定位的段都有一個相對于重定位段(表)， 利用objdump -r xx.o 可以查看目標文件的重定位表。

對于弱符號，即未初始化的全局變量，由于在編譯成目標文件之后，編譯器不能確定其大小，所以將其放在COMMON塊中，但是當鏈接器分析完各個目標文件之后就可以確定其大小，從而將其放在BSS段，所以總體來看，未初始化的全局變量還是放在BSS段的。可以在GCC編譯的時候使用fno-common指定未賦值的全局變量不在COMMON塊中, 也可可以在代碼中寫__attribbute__ ((nocommon))將其當成強符號處理。

重復代碼消除，例如C++的模板技術使得模板可以在多個源文件中別實例化但是編譯器并不能知道它在多處被同一種數據類型實例化，所以現在主流編譯器例如GNU 的做法是在每一個目標文件中對于一個模板的同一種實例化使用一種相同的名稱，這樣在鏈接階段，鏈接器會檢查這些重復的段并只保留一份。GCC把這種段叫"Link Once"命名為".gnu.linkonce.name" . VC++叫做COMDAT，
這種做法的一個潛在的問題是，當編譯器對不同的編譯單元使用不同的編譯優(yōu)化選項的時候，可能會使得相同名稱的段有不同的內容，編譯器的做法是隨意選擇一個作為鏈接的輸入且提供警告信息。

函數級別鏈接: 通常的鏈接過程都是文件或者編譯單元級別的鏈接，但是當只需要使用某個目標為見中的一個函數或變量的時候，就需要全部包含該文件，導致體積很大，編譯器為此專門提供了函數級別的鏈接，與重復代碼消除和相似，編譯器將所有函數都想模板函數一樣單獨保存到一個段中，需要的時候再將其包含到輸出文件，其他的則直接拋棄，這雖然較小的最終文件的體積但是由于段的數目增減，減慢了編譯和鏈接的過程。GCC使用-fdata-sections和-ffunction-sections可以將變量或者函數分別保存到獨立的段中。

全局構造與析構: 全局對象的構造在main函數之前執(zhí)行，全局對象的析構在main函數之后哦執(zhí)行，Linux下的入口函數是_start,用于在main執(zhí)行前進行初始化。為此，ELF文件提供了兩個特殊的段.init和.fini。其中.init中保存的指令是main執(zhí)行之前Glibc的初始化部分， .fini中是main函數正常退出之后Glibc會安排執(zhí)行的代碼。

為了使得不同平臺的目標文件兼容，即可以相互鏈接，這些文件必須有一直的ABI(Application Binary Interface),即二進制兼容，ABI內容包括符號修飾標準，變量內存布局，函數調用方式等等。廠商不希望用戶看見自己的源代碼所以會提供二進制版本，所以二進制兼容在大型項目中變得很重要。目前編譯器的兩大陣營 VISUAL C++和GNU 的GCC各執(zhí)己見互不兼容。ABI兼容問題還有待解決

一個靜態(tài)庫文件（.a）是由許多.o文件合并而來的，linux下使用ar -t xx.a可以查看.a文件中包含的.o文件。在windows平臺下可以使用lib /LIST xx.lib查看

可以使用objdump -t xx.a | grep xxx查找特定的目標文件。使用gcc -static --verbose -fno-builtin hello.c可以將編譯鏈接過程的中間步驟打印出來， 即使我們寫的代碼非常簡單，這也是一個非常長的依賴關系。這個過程會鏈接部分會顯示collect2這是ld的一個包裝，會調用ld

BFD(Binary File Descriptor library)是基于所有硬件平臺（不同的處理器和目標文件格式）的一個抽象層，基于BFD可以不用關心具體的硬件格式，而進行統(tǒng)一操作，因為BFD中已經包含了這些CPU和可執(zhí)行文件的格式信息，ubuntu下BFD軟件包的名字叫binutils-dev.

windows上的目標文件為COEF格式，而可執(zhí)行文件是PE格式，PE又是COEF格式衍生出來的， 所以將這類文件統(tǒng)稱為PE/COEF格式

64位的Windows中對PE文件格式做了一點小小的修改，叫做PE32+格式，只是將32位的字段換成了64位而已。

VC++有一些對C/C++的專用拓展，使用cl編譯的時候，可以使用 /Za來禁用這些拓展，也可以在程序中使用宏__STDC__來查看VC++是否禁用了這些語法拓展

和GNU對象，Windows上的cl就是gcc， link就是ld， dumpbin就是objdump，

PE中有兩個ELF文件中不存在的段，分別是.drectve和 .debug$S. .drectve段是編譯器傳遞給鏈接器的指令，其中的flags表示了他的特點。 .debug$S表示的是符號相關的調試信息。其中有原始文件信息和編譯器信息

可以在cl命令中通過/ZI來關掉默認C庫的鏈接指令

PE文件為了兼容DOS的MZ文件結構在PE文件中加入了DOS的相關設置，所以將windows下的可執(zhí)行文件在DOS上運行的時候會輸出"This program cannot be run in DOS"

程序和進程的區(qū)別，程序就是菜譜，是一個靜態(tài)概念， 進程就是菜，是一個動態(tài)概念。

程序的尋址空間由CPU的位數決定，所以32位下的程序尋址空間是$2^{32}bit$即4GB， 64位下是17179869184 GB, 32位下C語言指針的長度是4字節(jié)，64位系統(tǒng)下長度是8字節(jié).