by falcon<zhangjinw@gmail.com>
2008-02-29
代碼寫完以后往往要做測試（或驗證）、調試，可能還要優化。
關于測試（或驗證），通常對應著兩個英文單詞verification和validation，在資料[1]中有關于這個的定義和一些深入的討論，在資料[2]中，很多人給出了自己的看法。但是我想正如資料[2]提到的：
“The differences between verification and validation are unimportant
except to the theorist; practitioners use the term V&V to refer to
all ofthe activities that are aimed at making sure the software will
function as required.”
所以，無論測試（或驗證）目的都是為了讓軟件的功能能夠達到需求。測試和驗證通常會通過一些形式化（貌似可以簡單地認為有數學根據的）或者非形式化的方法去驗證程序的功能是否達到要求。
而調試對應英文debug，debug叫“驅除害蟲”，也許一個軟件的功能達到了要求，但是可能會在測試或者是正常運行時出現異常，因此需要處理它們。
關于優化：debug是為了保證程序的正確性，之后就需要考慮程序的執行效率，對于存儲資源受限的嵌入式系統，程序的大小也可能是優化的對象。
很多理論性的東西是在沒有研究過，暫且不說吧。這里只是想把一些需要動手實踐的東西先且記錄和總結一下，另外很多工具在這里都有提到和羅列，包括Linux內核調試相關的方法和工具。關于更詳細更深入的內容還是建議直接看后面的參考資料為妙。
下面的所有演示在如下環境下進行：
| Quote: |
|
$ uname -a
Linux falcon 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux
$ echo $SHELL
/bin/bash
$ /bin/bash --version | grep bash
GNU bash, version 3.2.25(1)-release (i486-pc-linux-gnu)
$ gcc --version | grep gcc
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
$ cat /proc/cpuinfo | grep "model name"
model name : Intel(R) Pentium(R) 4 CPU 2.80GHz
|
1、代碼測試
代
碼測試有很多方面呢，例如運行時間、函數調用關系圖、代碼覆蓋度、性能測試(profiling)、內存訪問越界(segmentation
fault)、緩沖區溢出（stack smashing合法地進行非法的內存訪問？所以很危險）、內存泄露(memory leak)等。
1.1 測試程序的運行時間 time
shell提供了內置命令time用于測試程序的執行時間，默認顯示結果包括三部分：實際花費時間(real time)、用戶空間花費時間(user time)和內核空間花費時間(kernel time)。
| Quote: |
|
$ time pstree 2>&1 >/dev/null
real 0m0.024s
user 0m0.008s
sys 0m0.004s
|
time
命令給出了程序本身的運行時間。這個測試原理非常簡單，就是在程序運行(通過system函數執行)前后記錄了系統時間(用times函數)，然后進行求
差就可以。如果程序運行時間很短，運行一次看不到效果，可以考慮采用測試紙片厚度的方法進行測試，類似把很多紙張跌倒一起來測試紙張厚度一樣，我們可以讓
程序運行很多次。
如果程序運行時間太長，執行效率很低，那么得考慮程序內部各個部分的執行情況，從而對代碼進行可能的優化。具體可能會考慮到這兩點：
對于C語言程序而言，一個比較宏觀的層次性的輪廓(profile)是函數調用圖、函數內部的條件分支構成的語句塊，然后就是具體的語句。把握好這樣一個
輪廓后，就可以有針對性地去關注程序的各個部分，包括哪些函數、哪些分支、哪些語句最值得關注（執行次數越多越值得優化，術語叫hotspots）。
對于Linux下的程序而言，程序運行時涉及到的代碼會涵蓋兩個空間，即用戶空間和內核空間。由于這兩個空間涉及到地址空間的隔離，在測試或調試時，可能
涉及到兩個空間的工具。前者絕大多數是基于gcc的特定參數和系統的ptrace調用，而后者往往實現為內核的補丁，它們在原理上可能類似，但實際操作時
后者顯然會更麻煩，不過如果你不去hack內核，那么往往無須關心后者。
1.2 函數調用關系圖 calltree
calltree可以非常簡單方便地反應一個項目的函數調用關系圖，雖然諸如gprof這樣的工具也能做到，不過如果僅僅要得到函數調用圖，calltree應該是更好的選擇。如果要產生圖形化的輸出可以使用它的-dot參數也可以參考資料[12]。從這里可以下載到它，ftp://ftp.berlios.de/pub/calltree/calltree-2.3.tar.bz2
關于calltree的實現原理，可以參考資料[13]，關于它的詳細用法請參考資料[14]或者它的-h參數獲取幫助。
這里是一份演示結果，
| Quote: |
|
$ calltree -b -np -m *.c
main:
| close
| commitchanges
| | err
| | | fprintf
| | ferr
| | ftruncate
| | lseek
| | write
| ferr
| getmemorysize
| modifyheaders
| open
| printf
| readelfheader
| | err
| | | fprintf
| | ferr
| | read
| readphdrtable
| | err
| | | fprintf
| | ferr
| | malloc
| | read
| truncatezeros
| | err
| | | fprintf
| | ferr
| | lseek
| | read$
|
這
樣一份結果對于“反向工程”應該會很有幫助，它能夠呈現一個程序的大體結構，對于閱讀和分析源代碼來說是一個非常好的選擇。雖然cscope和ctags
也能夠提供一個函數調用的“即時”（在編輯vim的過程中進行調用）視圖（view），但是calltree卻給了我們一個宏觀的視圖。
不過這樣一個視圖只涉及到用戶空間的函數，如果想進一步給出內核空間的宏觀視圖，那么strace和KFT就可以發揮它們的作用。關于這兩個工具請參考條目[11]列出的相關資料。另外，該視圖也沒有給出庫中的函數，如果要跟蹤呢？需要ltrace工具。
另外，我們發現，calltree僅僅給出了一個程序的函數調用視圖，而沒有告訴我們各個函數的執行次數等情況。如果要關注這些呢？我們有gprof。
1.3 性能測試工具 gprof & kprof
參考資料[3]詳細介紹了這個工具的用法，這里僅挑選其中一個例子來演示。gprof是一個命令行的工具，而KDE桌面環境下的kprof則給出了圖形化的輸出，這里僅演示前者。
首先來看一段代碼(來自資料[3])，算Fibonacci數列的，
Code:
[Ctrl+A Select All]
通過calltree看看這段代碼的視圖，
| Quote: |
|
$ calltree -b -np -m *.c
main:
| fibonacci
| | fibonacci ....
| printf
|
可以看出程序主要涉及到一個fibonacci函數，這個函數遞歸調用自己。為了能夠使用gprof，需要編譯時加上-pg選項，讓gcc加入相應的調試信息以便gprof能夠產生函數執行情況的報告。
| Quote: |
|
$ gcc -pg -o fib fib.c
$ ls
fib fib.c
|
運行程序并查看執行時間，
| Quote: |
|
$ time ./fib
fibonnaci(0) = 0
fibonnaci(1) = 1
fibonnaci(2) = 1
fibonnaci(3) = 2
...
fibonnaci(41) = 165580141
fibonnaci(42) = 267914296
real 1m25.746s
user 1m9.952s
sys 0m0.072s
$ ls
fib fib.c gmon.out
|
上面僅僅選取了部分執行結果，程序運行了1分多鐘，代碼運行以后產生了一個gmon.out文件，這個文件可以用于gprof產生一個相關的性能報告。
| Quote: |
|
$ gprof -b ./fib gmon.out
Flat profile:
Each sample counts as 0.01 seconds.
% cumulative self self total
time seconds seconds calls ms/call ms/call name
96.04 14.31 14.31 43 332.80 332.80 fibonacci
4.59 14.99 0.68 main
Call graph
granularity: each sample hit covers 2 byte(s) for 0.07% of 14.99 seconds
index % time self children called name
<spontaneous>
[1] 100.0 0.68 14.31 main [1]
14.31 0.00 43/43 fibonacci [2]
-----------------------------------------------
2269806252 fibonacci [2]
14.31 0.00 43/43 main [1]
[2] 95.4 14.31 0.00 43+2269806252 fibonacci [2]
2269806252 fibonacci [2]
-----------------------------------------------
Index by function name
[2] fibonacci [1] main
|
從
這份結果中可觀察到程序中每個函數的執行次數等情況，從而找出值得修改的函數。在對某些部分修改之后，可以再次比較程序運行時間，查看優化結果。另外，這
份結果還包含一個特別有用的東西，那就是程序的動態函數調用情況，即程序運行過程中實際執行過的函數，這和calltree產生的靜態調用樹有所不同，它
能夠反應程序在該次執行過程中的函數調用情況。而如果想反應程序運行的某一時刻調用過的函數，可以考慮采用gdb的backtrace命令。
類似測試紙片厚度的方法，gprof也提供了一個統計選項，用于對程序的多次運行結果進行統計。另外，gprof有一個KDE下圖形化接口kprof，這兩部分請參考資料[3]。
gprof雖然給出了函數級別的執行情況，但是如果想關心具體哪些條件分支被執行到，哪些語句沒有被執行，該怎么辦？
1.4 代碼覆蓋率測試 gcov & ggcov
如果要使用gcov，在編譯時需要加上這兩個選項 -fprofile-arcs -ftest-coverage，這里直接用之前的fib.c做演示。
| Quote: |
|
$ ls
fib.c
$ gcc -fprofile-arcs -ftest-coverage -o fib fib.c
$ ls
fib fib.c fib.gcno
|
運行程序，并通過gcov分析代碼的覆蓋度
| Quote: |
|
$ ./fib
$ gcov fib.c
File 'fib.c'
Lines executed:100.00% of 12
fib.c:creating 'fib.c.gcov'
|
12行代碼100%被執行到，再查看分支情況，
| Quote: |
|
$ gcov -b fib.c
File 'fib.c'
Lines executed:100.00% of 12
Branches executed:100.00% of 6
Taken at least once:100.00% of 6
Calls executed:100.00% of 4
fib.c:creating 'fib.c.gcov'
|
發
現所有函數，條件分支和語句都被執行到，說明代碼的覆蓋率很高，不過資料[3]gprof的演示顯示代碼的覆蓋率高并不一定說明代碼的性能就好，因為那些
被覆蓋到的代碼可能能夠被優化成性能更高的代碼。那到底那些代碼值得被優化呢？執行次數最多的，另外，有些分支雖然都覆蓋到了，但是這個分支的位置可能并
不是理想的，如果一個分支的內容被執行的次數很多，那么把它作為最后一個分支的話就會浪費很多不必要的比較時間。因此，通過覆蓋率測試，可以嘗試著剔除那
些從未執行過的代碼，通過性能測試，可以找出那些值得優化的函數、分支或者是語句。
如果使用-fprofile-arcs -ftest-coverage參數編譯完代碼，可以接著用-fbranch-probabilities參數對代碼進行編譯，這樣，編譯器就可以對根據代碼的分支測試情況進行優化。
| Quote: |
|
$ wc -c fib
16333 fib
$ ls fib.gcda #確保fib.gcda已經生成，這個是運行fib后的結果，-fbranch-probabilities一來它
fib.gcda
$ gcc -fbranch-probabilities -o fib fib.c #再次運行
$ wc -c fib
6604 fib
$ time ./fib
...
real 0m21.686s
user 0m18.477s
sys 0m0.008s
|
可見代碼量減少了，而且執行效率會有所提高，當然，這個代碼效率的提高可能還跟其他因素有關，比如gcc還優化了一些很平臺相關的指令。
如
果想看看代碼中各行被執行的情況，可以直接看fib.c.gcov文件。這個文件的各列依次表示執行次數、行號和該行的源代碼。次數有三種情況，如果一直
沒有執行，那么用####表示；如果該行注釋、函數聲明等，用-表示；如果是純粹的代碼行，那么用執行次數表示。這樣我們就可以直接分析每一行的執行情
況。
gprof也有一個圖形化接口ggprof，是基于gtk+的，適合Gnome桌面的用戶。
現在都已經關注到代碼行
了，實際上優化代碼的前提是保證代碼的正確性，如果代碼還有很多bug，那么先要debug。不過下面的這些"bug"用普通的工具確實不太方便，雖然可
能，不過這里還是把它們歸結為測試的內容，并且這里剛好承接上gcov部分，gcov能夠測試到每一行的代碼覆蓋情況，而無論是內存訪問越界、緩沖區溢出
還是內存泄露，實際上是發生在具體的代碼行上的。
1.5 內存訪問越界 catchesegv, libSegFault.so
"segmentation fault"是很頭痛的一個問題，估計“糾纏”過很多人。這里僅僅演示通過catchsegv腳本測試段錯誤的方法，其他方法見資料[15]。
catchsegv利用系統動態鏈接的PRELOAD機制（請參考man ld-linux），把庫/lib/libSegFault.so提前load到內存中，然后通過它檢查程序運行過程中的段錯誤。
| Quote: |
|
$ cat test.c
#include <stdio.h>
int main(void)
{
char str[10];
sprintf(str, "%s", 111);
printf("str = %s\n", str);
return 0;
}
$ make test
$ LD_PRELOAD=/lib/libSegFault.so ./test #等同于catchsegv ./test
*** Segmentation fault
Register dump:
EAX: 0000006f EBX: b7eecff4 ECX: 00000003 EDX: 0000006f
ESI: 0000006f EDI: 0804851c EBP: bff9a8a4 ESP: bff9a27c
EIP: b7e1755b EFLAGS: 00010206
CS: 0073 DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
Trap: 0000000e Error: 00000004 OldMask: 00000000
ESP/signal: bff9a27c CR2: 0000006f
Backtrace:
/lib/libSegFault.so[0xb7f0604f]
[0xffffe420]
/lib/tls/i686/cmov/libc.so.6(vsprintf+0x8c)[0xb7e0233c]
/lib/tls/i686/cmov/libc.so.6(sprintf+0x2e)[0xb7ded9be]
./test[0x804842b]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb7dbd050]
./test[0x8048391]
...
|
從
結果中可以看出，代碼的sprintf有問題。經過檢查發現它把整數當字符串輸出，對于字符串的輸出，需要字符串的地址作為參數，而這里的111則剛好被
解釋成了字符串的地址，因此sprintf試圖訪問111這個地址，從而發生了非法訪問內存的情況，出現"segmentation fault"。
1.6 緩沖區溢出 libsafe.so
緩
沖區溢出是指棧溢出(stack
smashing)，通常發生在對函數內的局部變量進行賦值操作時，超出了該變量的字節長度而引起對棧內原有數據（比如eip,ebp等）的覆蓋，從而引
發內存訪問越界，甚至執行非法代碼，導致系統崩潰。關于緩沖區的詳細原理和實例分析見資料[16]。這里僅僅演示該資料中提到的一種用于檢查緩沖區溢出的
方法，它同樣采用動態鏈接的PRELOAD機制提前裝載一個名叫libsafe.so的庫，你可以從這里獲取它，http://www.sfr-fresh.com/linux/misc/libsafe-2.0-16.tgz，下載下來以后，再解壓，編譯，得到libsafe.so，
下面，演示一個非常簡單的，但可能存在緩沖區溢出的代碼，并演示libsafe.so的用法。
| Quote: |
|
$ cat test.c
$ make test
$ LD_PRELOAD=/path/to/libsafe.so ./test ABCDEFGHIJKLMN
ABCDEFGHIJKLMN
*** stack smashing detected ***: ./test terminated
Aborted (core dumped)
|
資
料[6]分析到，如果不能夠對緩沖區溢出進行有效的處理，可能會存在很多潛在的危險。雖然libsafe.so采用函數替換的方法能夠進行對這類
stack
smashing進行一定的保護，但是無法根本解決問題，alert7大蝦在資料[17]中提出了突破它的辦法，資料[18]提出了另外一種保護機制。
1.7 內存泄露 Memwatch, Valgrind, mtrace
堆
棧通常會被弄在一起叫，不過這兩個名詞卻是指進程的內存映像中的兩個不同的部分，棧(stack)用于函數的參數傳遞、局部變量的存儲等，是系統自動分配
和回收的；而堆(heap)則是用戶通過malloc等方式申請而且需要用戶自己通過free釋放的，如果申請的內存沒有釋放，那么將導致內存泄露，進而
可能導致堆的空間被用盡；而如果已經釋放的內存再次被釋放(double-free)則也會出現非法操作。(如果要真正理解堆和棧的區別，需要理解進程的
內存映像，請參考資料[22])
這里演示通過Memwatch來檢測程序中可能存在內存泄露，你可以從這里下載到這個工具，http://www.linkdata.se/sourcecode.html
使用這個工具的方式很簡單，只要把它鏈接(ld)到你的可執行文件中去，并在編譯時加上兩個宏開關-DMEMWATCH -DMW_STDIO。這里演示一個簡單的例子。
| Quote: |
|
$ cat test.c
#include <stdlib.h>
#include <stdio.h>
#include "memwatch.h"
int main(void)
{
char *ptr1;
char *ptr2;
ptr1 = malloc(512);
ptr2 = malloc(512);
ptr2 = ptr1;
free(ptr2);
free(ptr1);
}
$ gcc -DMEMWATCH -DMW_STDIO test.c memwatch.c -o test
$ cat memwatch.log
============= MEMWATCH 2.71 Copyright (C) 1992-1999 Johan Lindh =============
Started at Sat Mar 1 07:34:33 2008
Modes: __STDC__ 32-bit mwDWORD==(unsigned long)
mwROUNDALLOC==4 sizeof(mwData)==32 mwDataSize==32
double-free: <4> test.c(15), 0x80517e4 was freed from test.c(14)
Stopped at Sat Mar 1 07:34:33 2008
unfreed: <2> test.c(11), 512 bytes at 0x8051a14 {FE FE FE FE FE FE FE FE FE FE FE FE FE FE FE FE ................}
Memory usage statistics (global):
N)umber of allocations made: 2
L)argest memory usage : 1024
T)otal of all alloc() calls: 1024
U)nfreed bytes totals : 512
|
通過測試，可以看到有一個512字節的空間沒有被釋放，而另外512字節空間卻被連續釋放兩次(double-free)。valgrind和mtrace也可以做類似的工作，請參考資料[4]和mtrace的手冊。
2、代碼調試
調試的方法很多，調試往往要跟蹤代碼的運行狀態，printf是最基本的辦法，然后呢？靜態調試方法有哪些，非交互的呢？非實時的有哪些？實時的呢？用于調試內核的方法有哪些？有哪些可以用來調試匯編代碼呢？
2.1 靜態調試：printf + gcc -D（打印程序中的變量）
利
用gcc的宏定義開關(-D)和printf函數可以跟蹤程序中某個位置的狀態，這個狀態包括當前一些變量和寄存器的值。調試時需要用-D開關進行編譯，
在正式發布程序時則可把-D開關去掉。這樣做比單純用printf方便很多，它可以避免清理調試代碼以及由此帶來的誤刪除代碼等問題。
| Quote: |
|
$ cat test.c
#include <stdio.h>
#include <unistd.h>
int main(void)
{
int i = 0;
#ifdef DEBUG
printf("i = %d\n", i);
int t;
__asm__ __volatile__ ("movl %%ebp, %0;":"=r"(t)::"%ebp");
printf("ebp = 0x%x\n", t);
#endif
_exit(0);
}
$ gcc -DDEBUG -g -o test test.c
$ ./test
i = 0
ebp = 0xbfb56d98
|
上面演示了如何跟蹤普通變量和寄存器變量的辦法。跟蹤寄存器變量采用了內聯匯編，關于Linux下的匯編語言開發請參考資料[19]。
不
過，這種方式不夠靈活，我們無法“即時”獲取程序的執行狀態，而gdb等交互式調試工具不僅解決了這樣的問題，而且通過把調試器拆分成調試服務器和調試客
戶端適應了嵌入式系統的調試，另外，通過預先設置斷點以及斷點處需要收集的程序狀態信息解決了交互式調試不適應實時調試的問題。
2.2 交互式的調試（動態調試）：gdb（支持本地和遠程）/ald（匯編指令級別的調試）
2.2.1 嵌入式系統調試方法 gdbserver/gdb
估計大家已經非常熟悉GDB(Gnu DeBugger)了，所以這里并不介紹常規的gdb用法，而是介紹它的服務器／客戶(gdbserver/gdb)調試方式。這種方式非常適合嵌入式系統的調試，為什么呢？先來看看這個：
| Quote: |
|
$ wc -c /usr/bin/gdbserver
56000 /usr/bin/gdbserver
$ which gdb
/usr/bin/gdb
$ wc -c /usr/bin/gdb
2557324 /usr/bin/gdb
$ echo "(2557324-56000)/2557324" | bc -l
.97810210986171482377
|
gdb
比gdbserver大了將近97%，如果把整個gdb搬到存儲空間受限的嵌入式系統中是很不合適的，不過僅僅5K左右的gdbserver即使在只有
8M Flash卡的嵌入式系統中也都足夠了。所以在嵌入式開發中，我們通常先在本地主機上交叉編譯好gdbserver/gdb。
如果是初次使用這種方法，可能會遇到麻煩，而麻煩通常發生在交叉編譯gdb和gdbserver時。在編譯gdbserver/gdb前，需要配置(./configure)兩個重要的選項：
--host，指定gdb/gdbserver本身的運行平臺，
--target，指定gdb/gdbserver調試的代碼所運行的平臺，
關
于運行平臺，通過$MACHTYPE環境變量就可獲得，對于gdbserver，因為要把它復制到嵌入式目標系統上，并且用它來調試目標平臺上的代碼，因
此需要把--host和--target都設置成目標平臺；而gdb因為還是運行在本地主機上，但是需要用它調試目標系統上的代碼，所以需要把--
target設置成目標平臺。
編譯完以后就是調試，調試時需要把程序交叉編譯好，并把二進制文件復制一份到目標系統上，并在本地需要保留一份源代碼文件。調試過程大體如下，首先在目標系統上啟動調試服務器：
| Quote: |
|
$ gdbserver :port /path/to/binary_file
...
|
然后在本地主機上啟動gdb客戶端鏈接到gdb調試服務器，（gdbserver_ipaddress是目標系統的IP地址，如果目標系統不支持網絡，那么可以采用串口的方式，具體看手冊）
| Quote: |
|
$ gdb
...
(gdb) target remote gdbserver_ipaddress:2345
...
|
其他調試過程和普通的gdb調試過程類似。
2.2.2 匯編代碼的調試 ald
用gdb調試匯編代碼貌似會比較麻煩，不過有人正是因為這個原因而開發了一個專門的匯編代碼調試器，名字就叫做assembly language debugger，簡稱ald，你可以從這里下載到，http://ald.sourceforge.net/
下載以后，解壓編譯后，我們來調試一個程序看看。
這里是一段非常簡短的匯編代碼，摘自參考資料[20]
Code:
[Ctrl+A Select All]
演示一下，
| Quote: |
|
//匯編、鏈接、運行
$ as -o test.o test.s
$ ld -o test test.o
$ ./test "Hello World"
Hello World
//查看程序的入口地址
$ readelf -h test | grep Entry
Entry point address: 0x8048054
//調試
$ ald test
ald> display
Address 0x8048054 added to step display list
ald> n
eax = 0x00000000 ebx = 0x00000000 ecx = 0x00000001 edx = 0x00000000
esp = 0xBFBFDEB4 ebp = 0x00000000 esi = 0x00000000 edi = 0x00000000
ds = 0x007B es = 0x007B fs = 0x0000 gs = 0x0000
ss = 0x007B cs = 0x0073 eip = 0x08048055 eflags = 0x00200292
Flags: AF SF IF ID
Dumping 64 bytes of memory starting at 0x08048054 in hex
08048054: 59 59 59 C6 41 0C 0A 31 D2 B2 0D 31 C0 B0 04 31 YYY.A..1...1...1
08048064: DB CD 80 31 C0 40 CD 80 00 2E 73 79 6D 74 61 62 ...1.@....symtab
08048074: 00 2E 73 74 72 74 61 62 00 2E 73 68 73 74 72 74 ..strtab..shstrt
08048084: 61 62 00 2E 74 65 78 74 00 00 00 00 00 00 00 00 ab..text........
08048055 59 pop ecx
|
可見ald在啟動時就已經運行了被它調試的test程序，并且進入了程序的入口0x8048054，緊接著單步執行時，就執行了程序的第一條指令popl ecx。
ald的命令很少，而且跟gdb很類似，比如
這個幾個命令用法和名字都類似 help,next,continue,set args,break,file,quit,disassemble,enable,disable等
名字不太一樣，功能對等的，examine對x, enter 對 set variable {int}地址=數據
需
要提到的是：linux下的調試器包括上面的gdb和ald，以及strace等都用到了linux系統提供的ptrace()系統調用，這個調用為用戶
訪問內存映像提供了便利，如果想自己寫一個調試器或者想hack一下gdb和ald，那么好好閱讀資料[10]和man ptrace吧。
2.3 實時調試：gdb tracepoint
對
于程序狀態受時間影響的程序，用上述普通的設置斷點的交互式調試方法并不合適，因為這種方式將由于交互時產生的通信延遲和用戶輸入命令的時延而完全改變程
序的行為。所以gdb提出了一種方法以便預先設置斷點以及在斷點處需要獲取的程序狀態，從而讓調試器自動執行斷點處的動作，獲取程序的狀態，從而避免在斷
點處出現人機交互產生時延改變程序的行為。
這種方法叫tracepoints(對應breakpoint)，它在gdb的user
manual(見資料[21])里頭有詳細的說明，不過在gdb的官方發行版中至今都沒有對它的實現。盡管如此，我們還是可以使用它，因為有其他組織做了
相關的工作，并以補丁的方式發布它。這個補丁你可以從這里獲取ftp://dslab.lzu.edu.cn/pub/gdb_tracepoints
獲
取這個補丁以后，要做的就是把它patch到對應的gdb版本中，然后就是編譯。因為tracepoints只定義在調試服務器和調試客戶端這種方式中，
因此在這個實現中也是這樣，如果想用它，你同樣需要編譯gdbserver和gdb，并類似嵌入式系統中的調試方法一樣調試它。
編譯好以后通過ftp://dslab.lzu.edu.cn/pub/gdb_tracepoints/paper/tp.pdf和資料[21]就可以使用它。
2.4 調試內核
雖然這里并不會演示如何去hack內核，但是相關的工具還是需要簡單提到的，資料[11]列出了絕大部分用于內核調試的工具，這些對你hack內核應該會有幫助的。
3、代碼優化
除了資料[21]中的實踐之外，我想我“應該”沒有做過其他的項目優化工作吧，所以很遺憾，這里無法進行討論了，不過我還是找了很多相關資料的，就讓大家一起分享吧，這些資料都列在條目
里。
實際上呢？“代碼測試”部分介紹的很多工具是為代碼優化服務的，更多具體的細節請參考后面的資料，自己做實驗吧。有任何相關的感興趣的話題歡迎給我郵件zhangjinw@gmail.com。
參考資料：
[1] VERIFICATION AND VALIDATION
http://satc.gsfc.nasa.gov/assure/agbsec5.txt
[2] difference between verification and Validation
http://www.faqs.org/qa/qa-9060.html
[3] Coverage Measurement and Profiling(覆蓋度測量和性能測試,Gcov and Gprof)
http://www.linuxjournal.com/article/6758
[4] Valgrind Usage
A. Valgrind HOWTO
http://www.faqs.org/docs/Linux-HOWTO/Valgrind-HOWTO.html
B. Using Valgrind to Find Memory Leaks and Invalid Memory Use
http://www.cprogramming.com/debugging/valgrind.html
[5] MEMWATCH
http://www.linkdata.se/sourcecode.html
[6] Mastering Linux debugging techniques
http://www.ibm.com/developerworks/linux/library/l-debug/
[7] Software Performance Analysis
http://arxiv.org/pdf/cs.PF/0507073.pdf
[8] Runtime debugging in embedded systems
http://dslab.lzu.edu.cn/docs/publications/runtime_debug.pdf
[9] Tools Provided by System
ltrace,mtrace,strace
[10] Write your own debugger with the support ptrace()
A. Process Tracing Using Ptrace
http://linuxgazette.net/issue81/sandeep.html
http://linuxgazette.net/issue83/sandeep.html
B. Playing with ptrace
http://www.linuxjournal.com/article/6100
http://www.linuxjournal.com/node/6210/print
http://www.ecos.sourceware.org/ml/libc-hacker/1998-05/msg00277.html
[11] Kernel Debugging Relative Tools
A. KGDB
http://dslab.lzu.edu.cn/docs/publications/kernel_gdb.pdf
B. GCOV
http://linuxdevices.com/files/article062/der_herr_gcov.pdf
C. KFI & KFT
http://dslab.lzu.edu.cn/docs/publications/kfi.pdf
D. UML(User Mode Linux)
http://dslab.lzu.edu.cn/docs/publications/uml.pdf
E. GDB Tracepoint
http://dslab.lzu.edu.cn/docs/publications/tp.pdf
F. Tools Collections
http://dslab.lzu.edu.cn/docs/publications/tools.pdf
G. Linux系統內核的調試
http://www.ibm.com/developerworks/cn/linux/l-kdb/
H. 嵌入式Linux內核調試技術
http://www.eepw.com.cn/article/73300.htm
[12] 用Graphviz進行可視化操作──繪制函數調用關系圖
http://oss.lzu.edu.cn/blog/blog.php?do_showone/tid_1425.html
[13] 用 Graphviz 可視化函數調用
http://www.ibm.com/developerworks/cn/linux/l-graphvis/
[14] 介紹一個linux下生成C代碼調用樹的好工具calltree
http://www.linuxsir.org/bbs/printthread.php?t=246389
[15] 可惡的"Segmentation faults"之初級總結篇
http://oss.lzu.edu.cn/blog/article.php?tid_700.html
[16] Linux下緩沖區溢出攻擊的原理及對策
http://www.ibm.com/developerworks/cn/linux/l-overflow/index.html
[17] 繞過libsafe的保護--覆蓋_dl_lookup_versioned_symbol技術
http://www.xfocus.net/articles/200208/423.html
[18] 介紹Propolice怎樣保護stack-smashing的攻擊
http://www.xfocus.net/articles/200103/78.html
[19] Linux 匯編語言開發指南
http://www.ibm.com/developerworks/cn/linux/l-assembly/index.html
[20] 為你的可執行文件“減肥”
http://oss.lzu.edu.cn/blog/blog.php?do_showone/tid_1547.html
[21] GDB Tracepoints
http://sourceware.org/gdb/current/onlinedocs/gdb_11.html#SEC84
[22] C語言程序緩沖區注入分析(第一部分：進程的內存映像)
http://oss.lzu.edu.cn/blog/blog.php?do_showone/tid_1539.html
Code Optimize Relatie
A. Optimizing C Code
http://www.jukie.net/~bart/slides/c-opt/c-opt.ps
B. Performance programming for scientific computing
http://www.research.ibm.com/perfprog/course/course.html
C. Performance Programming
http://www-cse.ucsd.edu/users/carter/perfprog.html
D. Linux Profiling and Optimization
http://www.cs.princeton.edu/picasso/mats/mats_S07/Lucifredi_Lecture_Feb07.pdf
E. High-level code optimization
http://web.abo.fi/~mats/codeopt2007/handouts/High-level-opt.pdf
F. Code Optimization
http://library.simugraph.com/articles/opti/optimizing.html
摘要: by falcon<zhangjinw@gmail.com>2008-02-26
Linux支持動態連接庫，不僅節省了磁盤、內存空間，而且可以提高程序運行效率[1]。不過引入動態連接庫也可能會帶來很多問題，例如動態連接庫的調試
[4]、升級更新[5]和潛在的安全威脅[6][7]。這里主要討論符號的動態鏈接過程... 閱讀全文
摘要: by falcon <zhangjinw@gmail.com>2008-2-13
閑言戲語
最近在寫《Shell編程范例之進程操作》，到現在也沒完。本打算介紹進程的相關操作，后面竟寫到Linux下的C語言開發過程，想把文件是怎么變成進程
的整個過程給全部搗弄一遍。雖然到程序加載以及動態符號連接都已經很理解了，但是這伙卻被進程的內存映像給... 閱讀全文
by falcon<zhangjinw@gmail.com>
2008-02-15
(這一小節應該是作為《shell編程范例之進程操作》的一些補充性質的內容。)
當我們在Linux下的命令行輸入一個命令之后，這背后發生了什么？
1、什么是命令行接口
用戶使用計算機有兩種常見的方式，一種是圖形化的接口（GUI），另外一種則是命令行接口（CLI）。對于圖形化的接口，用戶點擊某個圖標就可啟動后
臺的某個程序；對于命令行的接口，用戶鍵入某個程序的名字就可啟動某個程序。這兩者的基本過程是類似的，都需要查找程序文件在磁盤上的位置，加載到內存并
通過不同的解釋器進行解析和運行。下面以命令行為例來介紹程序執行那一剎那發生的一些事情。
首先來介紹什么是命令行？命令行就是command
line，很直觀的概念就是系統啟動后的那個黑屏幕：有一個提示符，并有光標在閃爍的那樣一個終端，一般情況下可以用CTRL+ALT+F1-6切換到不同的終端；在GUI界
面下也會有一些偽終端，看上去和系統啟動時的那個終端沒有什么區別，也會有一個提示符，并有一個光標在閃爍。就提示符和響應用戶的鍵盤輸入而言，它們兩者
在功能上是一樣的，實際上它們就是同一個東西，你用下面的命令就可以把它們打印出來。
| Quote: |
|
$ echo $SHELL #打印當前SHELL，當前運行的命令行接口程序
/bin/bash
$ echo $$ #該程序對應的進程ID，$$是一個比較特殊的環境變量，它存放了當前進程ID
1481
$ ps -C bash #通過PS命令查看
PID TTY TIME CMD
1481 pts/0 00:00:00 bash
|
從上面的操作結果可以看出，當前命令行接口實際上是一個程序，那就是/bin/bash，它是一個實實在在的程序，它打印提示符，接受用戶輸入的命令，分
析命令序列并執行然后返回結果。不過/bin/bash僅僅是當前使用的命令行程序之一，還有很多具有類似功能的程序，比如/bin/tcsh,
bin/ash等。不過這里主要來討論bash了，討論它自己是怎么啟動的，它怎么樣處理用戶的輸入命令等后臺細節？
1.2 /bin/bash是什么時候啟動的
1.2.1 /bin/bash
先通過CTRL+ALT+F1切換到一個普通終端下面，一般情況下看到的是XXX login:
提示輸入用戶名，接著是提示輸入密碼，然后呢？就直接登錄到了我們的命令
行接口。實際上正是你輸入正確的密碼后，那個程序把/bin/bash給啟動了。那是什么東西提示"XXX
login:"的呢？正是/bin/login程序，那/bin/login程序怎么知道要啟動/bin/bash,而不是其他的/bin/tcsh呢？
/bin/login程序實際上會檢查我們的/etc/passwd文件，在這個文件里頭包含了用戶名、密碼和該用戶的登錄shell。密碼和用戶名匹配用戶的登錄，而登錄shell則作為用戶登錄后的命令行程序。看看/etc/passwd中典型的這么一行：
| Quote: |
|
$ cat /etc/passwd | grep falcon
falcon:x:1000:1000:falcon,,,:/home/falcon:/bin/bash
|
這個是我用的帳號的相關信息哦，看到最后一行沒？/bin/bash，這正是我登錄用的命令行解釋程序。至于密碼呢，看到那個x沒？這個x說明我的密碼被
保存在另外一個文件里頭/etc/shadow，而且密碼是經過加密的。至于這兩個文件的更多細節，看manual吧。
我們怎么知道剛好是/bin/login打印了"XXX login"呢？現在回顧一下很早以前學習的那個strace命令。我們可以用strace命令來跟蹤/bin/login程序的執行。
跟上面一樣，切換到一個普通終端，并切換到root用戶，用下面的命令：
| Quote: |
|
$ strace -f -o strace.out /bin/login
|
退出以后就可以打開strace.out文件，看看到底執行了哪些文件，讀取了哪些文件。從中我們可以看到正是/bin/login程序用execve調
用了/bin/bash命令。通過后面的演示，我們發現/bin/login只是在子進程里頭用execve調用了/bin/bash，因為在啟動
/bin/bash后，我們發現/bin/login并沒有退出。
1.2.2 /bin/login
那/bin/login又是怎么起來的呢？
下面再來看一個演示。先在一個可以登陸的終端下執行下面的命令。
| Quote: |
|
$ getty 38400 tty8 linux
|
getty命令停留在那里，貌似等待用戶的什么操作，現在切回到第8個終端，是不是看到有"XXX login:"的提示了。輸入用戶名并登錄，之后退出，回到第一個終端，發現getty命令已經退出。
類似地，我們也可以用strace命令來跟蹤getty的執行過程。在第一個終端下切換到root用戶。執行如下命令，
| Quote: |
|
$ strace -f -o strace.out getty 38400 tty8 linux
|
同樣在strace.out命令中可以找到該命令的相關啟動細節。比如，我們可以看到正是getty程序用execve系統調用執行了
/bin/login程序。這個地方，getty是在自己的主進程里頭直接執行了/bin/login，這樣/bin/login將把getty的進程空
間替換掉。
1.2.3 /sbin/getty
這里涉及到一個非常重要的東西了：/sbin/init，通過man init你可以查看到該命令的作用，它可是“萬物之王”（init is
the parent of all processes on the
system）哦。它是Linux系統默認啟動的第一個程序，負責進行Linux系統的一些初始化工作，而這些初始化工作的配置則是通過
/etc/inittab來做的。那么來看看/etc/inittab的一個簡單的example吧，可以通過man inittab查看相關幫助。
整個配置文件的語法非常簡單，就是下面一行的重復，
| Quote: |
|
id:runlevels:action:process
|
id就是一個唯一的編號，不用管它，一個名字而言，無關緊要。
runlevels是運行級別，整個還是比較重要的，理解運行級別的概念很有必要，它可以有如下的取值，
| Quote: |
|
0 is halt.
1 is single-user.
2-5 are multi-user.
6 is reboot.
|
不過，真正在配置文件里頭用的是1-5了，而0和6非常特別，除了用它作為init命令的參數關機和重啟外，似乎沒有哪個“傻瓜”把它寫在系統的配置文件
里頭，讓系統啟動以后就關機或者重啟。1代表單用戶，而2-5則代表多用戶。對于2-5可能有不同的解釋，比如在slackware
12.0上，2,3,5被用來作為多用戶模式，但是默認不啟動X windows(GUI接口），而4則作為啟動X windows的運行級別。
action是動作，它也有很多選擇，我們關心幾個常用的
initdefault 用來指定系統啟動后進入的運行級別，通常在/etc/inittab的第一條配置，如
這個說明默認運行級別是3，即多用戶模式，但是不啟動X window的那種。
sysinit 指定那些在系統啟動時將被執行的程序，例如
| Quote: |
|
si:S:sysinit:/etc/rc.d/rc.S
[quote]
在man
inittab中提到，對于sysinit,boot等動作，runlevels選項是不用管的，所以我們可以很容易解讀這條配置：它的意思是系統啟動時
將默認執行/etc/rc.d/rc.S文件，在這個文件里你可直接或者間接的執行你想讓系統啟動時執行的任何程序，完成系統的初始化。
wait，當進入某個特別的運行級別時，指定的程序將被執行一次，init將等到它執行完成，例如
[quote]
rc:2345:wait:/etc/rc.d/rc.M
|
這個說明無論是進入運行級別2,3,4,5中哪一個，/etc/rc.d/rc.M將被執行一次，并且有init等待它執行完成。
ctrlaltdel，當init程序接收到SIGINT信號時，某個指定的程序將被執行，我們通常通過按下CTRL+ALT+DEL，這個默認情況下將
給init發送一個SIGINT信號。如果我們想在按下這幾個鍵時，系統重啟，那么可以在/etc/inittab中寫入，
| Quote: |
|
ca::ctrlaltdel:/sbin/shutdown -t5 -r now
|
respawn，這個指定的進程將被重啟，任何時候當它退出時。這意味著你沒有辦法結束它，除非init自己結束了。例如，
| Quote: |
|
c1:1235:respawn:/sbin/agetty 38400 tty1 linux
|
這一行的意思非常簡單，就是系統運行在級別1,2,3,5時，將默認執行/sbin/agetty程序（這個類似于上面提到的getty程序），這個程序非常有意思，就是無論什么時候它退出，init將再次啟動它。這個有幾個比較有意思的問題：
在slackware
12.0下，當你把默認運行級別修改為4的時候，只有第6個終端可以用。原因是什么呢？因為類似上面的配置，因為那里只有1235，而沒有4，這意味著當
系統運行在第4級別時，其他終端下的/sbin/agetty沒有啟動。所以，如果想讓其他終端都可以用，把1235修改為12345即可。
另外一個有趣的問題就是：正是init程序在讀取這個配置行以后啟動了/sbin/agetty，這就是我們的/sbin/agetty的秘密。
還有一個問題：無論我們退出哪個終端，那個"XXX
login:"總是會被打印，原因是respawn動作有趣的性質，因為它告訴init，無論/sbin/agetty什么時候退出，重新把它啟動起來，
那跟"XXX
login:"有什么關系呢？從前面的內容，我們發現正是/sbin/getty(同agetty)啟動了/bin/login，而/bin/login
有啟動了/bin/bash，即我們的命令行程序。
而init程序作為“萬物之王”，它是所有進程的“父”（也可能是祖父……）進程，那意味著其他進程最多只能是它的兒子進程。而這個子進程是怎么創建的，
fork調用，而不是之前提到的execve調用。前者創建一個子進程，后者則會覆蓋當前進程。因為我們發現/sbin/getty運行時，init并沒
有退出，因此可以判斷是fork調用創建一個子進程后，才通過execve執行了/sbin/getty。
因此，我們可以總結出這么一個調用過程：
| Quote: |
|
fork execve execve fork execve
init --> init --> /sbin/getty --> /bin/login --> /bin/login --> /bin/bash
|
這里的execve調用以后，后者將直接替換前者，因此當我們鍵入exit退出/bin/bash以后，也就相當于/sbin/getty都已經結束了，
因此最前面的init程序判斷/sbin/getty退出了，又會創建一個子進程把/sbin/getty啟動，進而又啟動了/bin/login，又看
到了那個"XXX login:"。
通過ps和pstree命令看看實際情況是不是這樣，前者打印出進程的信息，后者則打印出調用關系。
| Quote: |
|
$ ps -ef | egrep "/sbin/init|/sbin/getty|bash|/bin/login"
root 1 0 0 21:43 ? 00:00:01 /sbin/init
root 3957 1 0 21:43 tty4 00:00:00 /sbin/getty 38400 tty4
root 3958 1 0 21:43 tty5 00:00:00 /sbin/getty 38400 tty5
root 3963 1 0 21:43 tty3 00:00:00 /sbin/getty 38400 tty3
root 3965 1 0 21:43 tty6 00:00:00 /sbin/getty 38400 tty6
root 7023 1 0 22:48 tty1 00:00:00 /sbin/getty 38400 tty1
root 7081 1 0 22:51 tty2 00:00:00 /bin/login --
falcon 7092 7081 0 22:52 tty2 00:00:00 -bash
|
我們過濾了一些不相干的數據。從上面的結果可以看到，除了tty2被替換成/bin/login外，其他終端都運行著/sbin/getty，說明終端2
上的進程是/bin/login，它已經把/sbin/getty替換掉，另外，我們看到-bash進程的父進程是7081剛好是/bin/login程
序，這說明/bin/login啟動了-bash，但是它并沒有替換掉/bin/login，而是成為了/bin/login的子進程，這說明
/bin/login通過fork創建了一個子進程并通過execve執行了-bash（后者通過strace跟蹤到）。而init呢，其進程ID是1，
是/sbin/getty和/bin/login的父進程，說明init啟動或者間接啟動了它們。下面通過pstree來查看調用樹，更清晰的看出上述關
系。
| Quote: |
|
$ pstree | egrep "init|getty|\-bash|login"
init-+-5*[getty]
|-login---bash
|-xfce4-terminal-+-bash-+-grep
|
結果顯示init是5個getty程序，login程序和xfce4-terminal的父進程，而后兩者則是bash的父進程，另外我們執行的grep命令則在bash上運行，是bash的子進程，這個將是我們后面關心的問題。
從上面的結果發現，init作為所有進程的父進程，它的父進程ID饒有興趣的是0，它是怎么被啟動的呢？誰才是真正的“造物主”？
1.2.4 誰啟動了/sbin/init
如果用過Lilo或者Grub這兩個操作系統引導程序，你可能會用到Linux內核的一個啟動參數init，當你忘記密碼時，可能會把這個參數設置成/bin/bash，讓系統直接進入命令行，而無須輸入帳號和密碼，這樣就可以方便地登錄密碼修改掉。
這個init參數是個什么東西呢？通過man
bootparam會發現它的秘密，init參數正好指定了內核啟動后要啟動的第一個程序，而如果沒有指定該參數，內核將依次查找/sbin/init,
/etc/init, /bin/init,
/bin/sh，如果找不到這幾個文件中的任何一個，內核就要恐慌（panic）了，并呆在那里一動不動了。
因此/sbin/init就是Linux內核啟動的。而Linux內核呢？是通過Lilo或者Grub等引導程序啟動的，Lilo和Grub都有相應的配
置文件，一般對應/etc/lilo.conf和/boot/grub/menu.lst，通過這些配置文件可以指定內核映像文件、系統根目錄所在分區、
啟動選項標簽等信息，從而能夠讓它們順利把內核啟動起來。
那Lilo和Grub本身又是怎么被運行起來的呢？還記得以前介紹的MBR不？MBR就是主引導扇區，一般情況下這里存放著Lilo和Grub的代碼，而
誰知道正好是這里存放了它們呢？BIOS，如果你用光盤安裝過操作系統的話，那么應該修改過BIOS的默認啟動設置，通過設置你可以讓系統從光盤、硬盤甚
至軟盤啟動。正是這里的設置讓BIOS知道了MBR處的代碼需要被執行。
那BIOS又是什么時候被起來的呢？加電自檢就執行到了這里。
更多系統啟動的細節，看看 "man boot-scripts" 吧。
到這里，/bin/bash的神秘面紗就被揭開了，它只是系統啟動后運行的一個程序而已，只不過這個程序可以響應用戶的請求，那它到底是如何響應用戶請求的呢？
1.3 /bin/bash如何處理用戶鍵入的命令
1.3.0 預備知識
在執行磁盤上某個程序時，我們通常不會指定這個程序文件的絕對路徑，比如要執行echo命令時，我們一般不會輸入/bin/echo，而僅僅是輸入
echo。那為什么這樣bash也能夠找到/bin/echo呢？原因是Linux操作系統支持這樣一種策略：shell的一個環境變量PATH里頭存放
了程序的一些路徑，當shell執行程序時有可能去這些目錄下查找。which作為shell（這里特指bash）的一個內置命令，如果用戶輸入的命令是
磁盤上的某個程序，它會返回這個文件的全路徑。
有三個東西和終端的關系很大，那就是標準輸入、標準輸出和標準錯誤，它們是三個文件描述符，一般對應描述符0,1,2。在C語言程序里頭，我們可以把它們
當作文件描述符一樣進行操作。在命令行下，則可以使用重定向字符>,<等對它們進行操作。對于標準輸出和標準錯誤，都默認輸出到終端，對于標
準輸入，也同樣默認從終端輸入。
1.3.1 哪種命令先被執行
在C語言里頭要寫一段輸入字符串的命令很簡單，調用scanf或者fgets就可以。這個在bash里頭應該是類似的。但是它獲取用戶的命令以后，如何分析命令，如何響應不同的命令呢？
首先來看看bash下所謂的命令，用最常見的test來作測試。
| Quote: |
|
$ test1 #隨便鍵入一個字符串test1，bash發出響應，告訴我們找不到這個程序
bash: test1: command not found
$ test #當我們鍵入test的時候，看不到任何輸出，唯一的響應是，新的命令提示符被打印了
$ type test
test is a shell builtin
#查看test這個命令的類型，即查看test將被如何解釋，type告訴我們test是一個內置命令，如果沒有理解錯，test應該是利用諸如case "test": do something;break;這樣的機制實現的。
$ which test #通過which查到/usr/bin下有一個test命令文件，在鍵入test時，到底哪一個被執行了呢？
/usr/bin/test
$ /usr/bin/test #執行這個呢？也沒什么反應，到底誰先被執行了？
|
從上面的演示中發現一個問題？如果輸入一個命令，這個命令要么就不存在，要么可能同時是shell的內置命令、也有可能是磁盤上環境變量PATH所指定的目錄下的某個程序文件。
考慮到test內置命令和/usr/bin/test命令的響應結果一樣，我們無法知道哪一個先被執行了，怎么辦呢？把/usr/bin/test替換成
一個我們自己的命令，并讓它打印一些信息(比如hello,world!)，這樣我們就知道到底誰被執行了。寫完程序，編譯好，命名為test放到
/usr/bin下（記得備份原來那個）。開始測試：
| Quote: |
|
$ test #鍵入test，還是沒有效果
$ /usr/bin/test #而鍵入絕對路徑呢，則打印了hello, world!誒，那默認情況下肯定是內置命令先被執行了
hello, world!
|
總結：內置命令比磁盤文件中的程序優先被bash執行
下面看看更多有趣的東西，鍵盤鍵入的命令還有可能是什么呢？因為bash支持別名和函數，所以還有可能是別名和函數，另外，如果PATH環境變量指定的不同目錄下有相同名字的程序文件，那到底哪個被優先找到呢？
下面再作一些實驗，
| Quote: |
|
$ alias test="ls -l" #把test命名為ls -l的別名
$ test #再執行test，竟然執行了ls -l，而不是什么也沒有，說明alias比內置命令更優先
total 9488
drwxr-xr-x 12 falcon falcon 4096 2008-02-21 23:43 bash-3.2
-rw-r--r-- 1 falcon falcon 2529838 2008-02-21 23:30 bash-3.2.tar.gz
$ function test { echo "hi, I'm a function"; } #定義一個名叫test的函數
$ test #執行一下，發現，還是執行了ls -l，說明function沒有alias優先級高
total 9488
drwxr-xr-x 12 falcon falcon 4096 2008-02-21 23:43 bash-3.2
-rw-r--r-- 1 falcon falcon 2529838 2008-02-21 23:30 bash-3.2.tar.gz
$ unalias test #把別名給去掉
$ test #現在執行的是函數，說明函數的優先級比內置命令也要高
hi, I'm a function
$ builtin test #如果在命令之前跟上builtin，那么將直接執行內置命令
$ unset test #要去掉某個函數的定義，這樣就可以
|
通過這個實驗我們得到一個命令的別名（alias)、函數(function)，內置命令（builtin)和程序(program)的執行優先次序：
| Quote: |
|
先 alias --> function --> builtin --> program 后
|
實際上，type命令會告訴我們這些細節，type -a會按照bash解析的順序依次打印該命令的類型，而type -t則會給出第一個將被解析的命令的類型，之所以要做上面的實驗，是為了讓大家加印象。
| Quote: |
|
$ type -a test
test is a shell builtin
test is /usr/bin/test
$ alias test="ls -l"
$ function test { echo "I'm a function"; }
$ type -a test
test is aliased to `ls -l'
test is a function
test ()
{
echo "I'm a function"
}
test is a shell builtin
test is /usr/bin/test
$ type -t test
alias
|
下面再看看PATH指定的多個目錄下有同名程序的情況。再寫一個程序，打印“hi, world!”，以示和"hello,
world!"的區別，放到PATH指定的另外一個目錄/bin下，為了保證測試的說服力，再寫一個放到另外一個叫/usr/local/sbin的目錄
下。
先看看PATH環境變量，確保它有/usr/bin,/bin和/usr/local/sbin這幾個目錄，然后通過type
-P(-P參數強制到PATH下查找，而不管是別名還是內置命令等，可以通過help type查看該參數的含義)查看，到底哪個先被執行。
| Quote: |
|
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
$ type -P test #可以看到/usr/local/sbin下的先被找到
/usr/local/sbin/test
$ rm /usr/local/sbin/test #把/usr/local/sbin/test下的給刪除掉
$ type -P test #現在/usr/bin下的先被找到
/usr/bin/test
$ type -a test #type -a也顯示類似的結果
test is aliased to `ls -l'
test is a function
test ()
{
echo "I'm a function"
}
test is a shell builtin
test is /usr/bin/test
test is /bin/test
|
可以找出這么一個規律：shell從PATH列出的路徑中依次查找用戶輸入的命令。考慮到程序的優先級最低，如果想優先執行磁盤上的程序文件test呢？那么就可以用test -P找出這個文件并執行就可以了。
補充：對于shell的內置命令，可以通過help command的方式獲得幫助，對于程序文件，可以查看用戶手冊（當然，這個需要安裝，一般叫做xxx-doc），man command。關于用戶手冊安裝辦法見在Linux下學會查看Man文檔
1.3.2 這些特殊字符是如何解析的：|, >, <, &
在命令行上，除了輸入各種命令以及一些參數外，比如上面type命令的各種參數-a,
-P等，對于這些參數，是傳遞給程序本身的，非常好處理，比如if,else條件分之或者switch,
case都可以處理。當然，在bash里頭可能使用專門的參數處理函數getopt和getopt_long來處理它們。
而|,>,<,&等字符，則比較特別，shell是怎么處理它們的呢？它們也被傳遞給程序本身嗎？可我們的程序內部一般都不處理這些字符的，所以應該是shell程序自己解析了它們。
先來看看這幾個字符在命令行的常見用法，
| Quote: |
|
$ cat < ./test.c #<字符表示：把test.c文件重定向為標準輸入，作為cat命令的輸入，而cat默認把內容輸出到標準輸出。
#include <stdio.h>
int main(void)
{
printf("hi, myself!\n");
return 0;
}
$ cat < ./test.c > test_new.c #>表示把標準輸出重定向為文件test_new.c，結果內容輸出到test_new.c
|
對于>,<,>>,<<,<>我們都稱之為重定向（redirect），shell到底是怎么進行所謂的“重定向”的呢？
這主要歸功于dup/fcntl等函數，它們可以實現：復制文件描述符，讓多個文件描述符共享同一個文件表項。比如，當把文件test.c重定向為標準輸
入時。假設之前用以打開test.c的文件描述符是5，現在就把5復制為了0，這樣當cat試圖從標準輸入讀出內容時，也就訪問了文件描述符5指向的文件
表項，接著讀出了文件內容。輸出重定向與此類似。其他的重定向，諸如>>, <<,
<>等雖然和>,<的具體實現功能不太一樣，但本質是一樣的，都是文件描述符的復制，只不過可能對文件操作有一些附加的限制，比
如>>在輸出時追加到文件末尾，而>則會從頭開始寫入文件，前者意味著文件的大小會增長，而后者則意味文件被重寫。
那么|呢？"|"被形象地稱為“管道”，實際上它就是通過C語言里頭的無名管道來實現的。先看一個例子，
| Quote: |
|
$ cat < ./test.c | grep hi
printf("hi, myself!\n");
|
在這個例子中，cat讀出了test.c文件中的內容，并輸出到標準輸出上，但是實際上輸出的內容卻只有一行，原因是這個標準輸出被“接到”了grep命令的標準輸入上，而grep命令只打印了包含“hi”字符串的一行。
這是怎么被“接”上的。cat和grep作為兩個單獨的命令，它們本身沒有辦法把兩者的輸入和輸出“接”起來。這正是shell自己的“杰作”，它通過C
語言里頭的pipe函數創建了一個管道(一個包含兩個文件描述符的整形數組，一個描述符用于寫入數據，一個描述符用于讀入數據)，并且通過
dup/fcntl把cat的輸出復制到了管道的輸入，而把管道的輸出則復制到了grep的輸入。這真是一個奇妙的想法。
那&呢？當你在程序的最后跟上這個奇妙的字符以后就可以接著做其他事情了，看看效果，
| Quote: |
|
$ sleep 50 & #讓程序在后臺運行
[1] 8261
$ fg %1 #提示符被打印出來，可以輸入東西，讓程序到前臺運行，無法輸入東西了，按下CTRL+Z，再讓程序到后臺運行
sleep 50
[1]+ Stopped sleep 50
$ fg %1 #再調到前臺
sleep 50
|
實際上&正是shell支持作業控制的表征，通過作業控制，用戶在命令行上可以同時作幾個事情（把當前不做的放到后臺，用&或者CTRL
+Z或者bg）并且可以自由的選擇當前需要執行哪一個（用fg調到前臺）。這在實現時應該涉及到很多東西，包括終端會話（session）、終端信號、前
臺進程、后臺進程等。而在命令的后面加上&后，該命令將被作為后臺進程執行，后臺進程是什么呢？這類進程無法接收用戶發送給終端的信號（如
SIGHUP,SIGQUIT,SIGINT），無法響應鍵盤輸入（被前臺進程占用著），不過可以通過fg切換到前臺而享受作為前臺進程具有的特權。
因此，當一個命令被加上&執行后，shell必須讓它具有后臺進程的特征，讓它無法響應鍵盤的輸入，無法響應終端的信號（意味忽略這些信號），并
且比較重要的是新的命令提示符得打印出來，并且讓命令行接口可以繼續執行其他命令，這些就是shell對&的執行動作。
還有什么神秘的呢？你也可以寫自己的shell了，并且可以讓內核啟動后就執行它l，在lilo或者grub的啟動參數上設置init=
/path/to/your/own/shell/program就可以。當然，也可以把它作為自己的登錄shell，只需要放到/etc/passwd
文件中相應用戶名所在行的最后就可以。不過貌似到現在還沒介紹shell是怎么執行程序，是怎樣讓程序變成進程的，所以繼續。
1.3.3 /bin/bash用什么魔法讓一個普通程序變成了進程
當我們從鍵盤鍵入一串命令，shell奇妙的響應了，對于內置命令和函數，shell自身就可以解析了（通過switch case之類的C語言語句）。但是，如果這個命令是磁盤上的一個文件呢。它找到該文件以后，怎么執行它的呢？
還是用strace來跟蹤一個命令的執行過程看看。
| Quote: |
|
$ strace -f -o strace.log /usr/bin/test
hello, world!
$ cat strace.log | sed -ne "1p" #我們對第一行很感興趣
8445 execve("/usr/bin/test", ["/usr/bin/test"], [/* 33 vars */]) = 0
|
從跟蹤到的結果的第一行可以看到bash通過execve調用了/usr/bin/test，并且給它傳了33個參數。這33個vars是什么呢？看看
declare -x的結果(這個結果只有32個，原因是vars的最后一個變量需要是一個結束標志，即NULL)。
| Quote: |
|
$ declare -x | wc -l #declare -x聲明的環境變量將被導出到子進程中
32
$ export TEST="just a test" #為了認證declare -x和之前的vars的個數的關系，再加一個
$ declare -x | wc -l
33
$ strace -f -o strace.log /usr/bin/test #再次跟蹤，看看這個關系
hello, world!
$ cat strace.log | sed -ne "1p"
8523 execve("/usr/bin/test", ["/usr/bin/test"], [/* 34 vars */]) = 0
|
通過這個演示發現，當前shell的環境變量中被設置為export的變量被復制到了新的程序里頭。不過雖然我們認為shell執行新程序時是在一個新的
進程里頭執行的，但是strace并沒有跟蹤到諸如fork的系統調用（可能是strace自己設計的時候并沒有跟蹤fork，或者是在fork之后才跟
蹤）。但是有一個事實我們不得不承認：當前shell并沒有被新程序的進程替換，所以說shell肯定是先調用fork(也有可能是vfork)創建了一
個子進程，然后再調用execve執行新程序的。如果你還不相信，那么直接通過exec執行新程序看看，這個可是直接把當前shell的進程替換掉的。
| Quote: |
|
exec /usr/bin/test
|
應該可以看到當前shell“嘩”（聽不到，突然沒了而已）的一下就沒有了。
下面來模擬一下shell執行普通程序。multiprocess相當于當前shell，而/usr/bin/test則相當于通過命令行傳遞給shell的一個程序。這里是代碼：
Code:
[Ctrl+A Select All]
運行看看，
| Quote: |
|
$ make multiprocess
$ ./multiprocess
child: my pid is 2251
child: my parent's pid is 2250
hello, world!
parent: my pid is 2250
parent: wait for my child exit successfully!
|
從執行結果可以看出，/usr/bin/test在multiprocess的子進程中運行并不干擾父進程，因為父進程一直等到了/usr/bin/test執行完成。
再回頭看看代碼，你會發現execlp并沒有傳遞任何環境變量信息給/usr/bin/test，到底是怎么把環境變量傳送過去的呢？通過man
exec我們可以看到一組exec的調用，在里頭并沒有發現execve，但是通過man
execve可以看到該系統調用。實際上exec的那一組調用都只是libc庫提供的，而execve才是真正的系統調用，也就是說無論使用exec調用
中的哪一個，最終調用的都是execve，如果使用execlp，那么execlp將通過一定的處理把參數轉換為execve的參數。因此，雖然我們沒有
傳遞任何環境變量給execlp，但是默認情況下，execlp把父進程的環境變量復制給了子進程，而這個動作是在execlp函數內部完成的。
現在，總結一下execve，它有有三個參數，
第一個是程序本身的絕對路徑，對于剛才使用的execlp，我們沒有指定路徑，這意味著它會設法到PATH環境變量指定的路徑下去尋找程序的全路徑。
第二個參數是一個將傳遞給被它執行的程序的參數數組指針。正是這個參數把我們從命令行上輸入的那些參數，諸如grep命令的-v等傳遞給了新程序，可以通過main函數的第二個參數char *argv[]獲得這些內容。
第三個參數是一個將傳遞給被它執行的程序的環境變量，這些環境變量也可以通過main函數的第三個變量獲取，只要定義一個char
*env[]就可以了，只是通常不直接用它罷了，而是通過另外的方式，通過extern char
**environ全局變量（環境變量表的指針）或者getenv函數來獲取某個環境變量的值。
當然，實際上，當程序被execve執行后，它被加載到了內存里，包括程序的各種指令、數據以及傳遞給它的各種參數、環境變量等都被存放在系統分配給該程序的內存空間中。
我們可以通過/proc/<pid>/maps把一個程序對應的進程的內存映象看個大概。
| Quote: |
|
$ cat /proc/self/maps #查看cat程序自身加載后對應進程的內存映像
08048000-0804c000 r-xp 00000000 03:01 273716 /bin/cat
0804c000-0804d000 rw-p 00003000 03:01 273716 /bin/cat
0804d000-0806e000 rw-p 0804d000 00:00 0 [heap]
b7c46000-b7e46000 r--p 00000000 03:01 87528 /usr/lib/locale/locale-archive
b7e46000-b7e47000 rw-p b7e46000 00:00 0
b7e47000-b7f83000 r-xp 00000000 03:01 466875 /lib/libc-2.5.so
b7f83000-b7f84000 r--p 0013c000 03:01 466875 /lib/libc-2.5.so
b7f84000-b7f86000 rw-p 0013d000 03:01 466875 /lib/libc-2.5.so
b7f86000-b7f8a000 rw-p b7f86000 00:00 0
b7fa1000-b7fbc000 r-xp 00000000 03:01 402817 /lib/ld-2.5.so
b7fbc000-b7fbe000 rw-p 0001b000 03:01 402817 /lib/ld-2.5.so
bfcdf000-bfcf4000 rw-p bfcdf000 00:00 0 [stack]
ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
|
關于程序加載和進程內存映像的更多細節請參考《C語言程序緩沖區注入分析》。
到這里，關于命令行的秘密都被“曝光”了，可以開始寫自己的命令行解釋程序了。
關于進程的相關操作請參考《shell編程范例之進程操作》。
補充：上面沒有討論到一個比較重要的內容，那就是即使execve找到了某個可執行文件，如果該文件屬主沒有運行該程序的權限，那么也沒有辦法運行程序。可通過ls -l查看程序的權限，通過chmod添加或者去掉可執行權限。
文件屬主具有可執行權限時才可以執行某個程序
| Quote: |
|
whoami
falcon
$ ls -l hello #查看用戶權限(第一個x表示屬主對該程序具有可執行權限
-rwxr-xr-x 1 falcon users 6383 2000-01-23 07:59 hello*
$ ./hello
Hello World
$ chmod -x hello #去掉屬主的可執行權限
$ ls -l hello
-rw-r--r-- 1 falcon users 6383 2000-01-23 07:59 hello
$ ./hello
-bash: ./hello: Permission denied
|
參考的資料：
[1] man boot-scripts
Linux啟動過程
[2] man bootparam
Linux內核啟動參數
[3] man 5 passwd
[4] man shadow
[5] "UNIX環境高級編程"，進程關系一章
[6] 2006,2007 Summer School hold by DSLab
http://dslab.lzu.edu.cn/docs/2007summerschool/index.html
http://dslab.lzu.edu.cn/docs/2006summerschool/index.html
(上接“GCC編譯的背后(第一部分：預處理和編譯)”)
3、匯編
開篇：這里實際上還是翻譯過程，只不過把作為中間結果的匯編代碼翻譯成了機器代碼，即目標代碼，不過它還不可以運行。如果要產生這一中間結果，可用gcc的-c選項，當然，也可通過as命令_匯編_匯編語言源文件來產生。
匯編是把匯編語言翻譯成目標代碼的過程，在學習匯編語言開發時，大家應該比較熟悉nasm匯編工具(支持Intel格式的匯編語言)了，不過這里主要用
as匯編工具來匯編AT&T格式的匯編語言，因為gcc產生的中間代碼就是AT&T格式的。下面來演示分別通過gcc的-c選項和as來
產生
目標代碼。
| Quote: |
|
$ file hello.s
hello.s: ASCII assembler program text
$ gcc -c hello.s #用gcc把匯編語言編譯成目標代碼
$
file hello.o
#file命令可以用來查看文件的類型，這個目標代碼是可重定位的(relocatable)，需
#要通過ld進行進一步的鏈接成可執行程序(executable)和共享庫(shared)
hello.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
$ as -o hello.o hello.s #用as把匯編語言編譯成目標代碼
$ file hello.o
hello.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
|
gcc和as默認產生的目標代碼都是ELF格式[6]的，因此這里主要討論ELF格式的目標代碼(如果
有時間再回顧一下a.out和coff格式，當然你也可以參考資料[15]，自己先了解一下，并結合objcopy來轉換它們，比較異同)。
目標代碼不再是普通的文本格式，無法直接通過文本編輯器瀏覽，需要一些專門的工具。如果想了解更多目標代碼的細節，區分relocatable（可重定
位）、executable（可執行）、shared
libarary（共享庫）的不同，我們得設法了解目標代碼的組織方式和相關的閱讀和分析工具。下面我們主要介紹這部分內容。
"BFD is a package which allows applications to use the same routines to
operate on object files whatever the object file format. A new object
file format can be supported simply by creating a new BFD back end and
adding it to the library."[24][25]。
binutils(GNU Binary
Utilities)的很多工具都采用這個庫來操作目標文件，這類工具有objdump,objcopy,nm,strip等(當然，你也可以利用它。如
果你深入了解ELF格式，那么通過它來分析和編寫Virus程序將會更加方便)，不過另外一款非常優秀的分析工具readelf并不是
基于這個庫，所以你也應該可以直接用elf.h頭文件中定義的相關結構來操作ELF文件。
下面將通過這些輔助工具(主要是readelf和objdump，可參考本節最后列出的資料[4])，結合ELF手冊[6](建議看第三篇中文版)來分析它們。
下面大概介紹ELF文件的結構和三種不同類型ELF文件的區別。
ELF文件的結構：
ELF Header(ELF文件頭)
Porgram Headers Table(程序頭表，實際上叫段表好一些，用于描述可執行文件和可共享庫)
Section 1
Section 2
Section 3
...
Section Headers Table(節區頭部表，用于鏈接可重定位文件成可執行文件或共享庫)
對于可重定位文件，程序頭是可選的，而對于可執行文件和共享庫文件（動態連接庫），節區表則是可選的。這里的可選是指沒有也可以。可以分別通過
readelf文件的-h，-l和-S參數查看ELF文件頭(ELF Header)、程序頭部表（Program Headers
Table，段表）和節區表(Section Headers Table)。
文件頭說明了文件的類型，大小，運行平臺，節區數目等。先來通過文件頭看看不同ELF的類型。為了說明問題，先來幾段代碼吧。
Code:[Ctrl+A Select All]Code:[Ctrl+A Select All]Code:[Ctrl+A Select All] 下面通過這幾段代碼來演示通過readelf -h參數查看ELF的不同類型。期間將演示如何創建動態連接庫(即可共享文件)、靜態連接庫，并比較它們的異同。
| Quote: |
|
$ gcc -c myprintf.c test.c #編譯產生兩個目標文件myprintf.o和test.o，它們都是可重定位文件(REL)
$ readelf -h test.o | grep Type
Type: REL (Relocatable file)
$ readelf -h myprintf.o | grep Type
Type: REL (Relocatable file)
$ gcc -o test myprintf.o test.o #根據目標代碼連接產生可執行文件，這里的文件類型是可執行的(EXEC)
$ readelf -h test | grep Type
Type: EXEC (Executable file)
$ ar rcsv libmyprintf.a myprintf.o #用ar命令創建一個靜態連接庫，靜態連接庫也是可重定位文件(REL)
$ readelf -h libmyprintf.a | grep Type #因此，使用靜態連接庫和可重定位文件一樣，它們之間唯一不
#同是前者可以是多個可重定位文件的“集合”。
Type: REL (Relocatable file)
$ gcc -o test test.o -llib -L./ #可以直接連接進去，也可以使用-l參數，-L指定庫的搜索路徑
$ gcc -Wall myprintf.o -shared -Wl,-soname,libmyprintf.so.0 -o libmyprintf.so.0.0
#編譯產生動態鏈接庫，并支持major和minor版本號，動態鏈接庫類型為DYN
$ ln -sf libmyprintf.so.0.0 libmyprintf.so.0
$ ln -sf libmyprintf.so.0 libmyprintf.so
$ readelf -h libmyprintf.so | grep Type
Type: DYN (Shared object file)
$ gcc -o test test.o -llib -L./ #編譯時和靜態連接庫類似，但是執行時需要指定動態連接庫的搜索路徑
$ LD_LIBRARY_PATH=./ ./test #LD_LIBRARY_PATH為動態鏈接庫的搜索路徑
$ gcc -static -o test test.o -llib -L./ #在不指定static時會優先使用動態鏈接庫，指定時則阻止使用動態連接庫
#這個時候會把所有靜態連接庫文件加入到可執行文件中，使得執行文件很大
#而且加載到內存以后會浪費內存空間，因此不建議這么做
|
經過上面的演示基本可以看出它們之間的不同。可重定位文件本身不可以運行，僅僅是作為可執行文件、靜態連接庫（也是可重定位文件）、動態連接庫的
“組件”。靜態連接庫和動態連接庫本身也不可以執行，作為可執行文件的“組件”，它們兩者也不同，前者也是可重定位文件（只不過可能是多個可重定位文件的
集合），并且在連接時加入到可執行文件中去；而動態連接庫在連接時，庫文件本身并沒有添加到可執行文件中，只是在可執行文件中加入了該庫的名字等信息，以
便在可執行文件運行過程中引用庫中的函數時由動態連接器去查找相關函數的地址，并調用它們。從這個意義上說，動態連接庫本身也具有可重定位的特征，含有可
重定位的信息。對于什么是重定位？如何進行靜態符號和動態符號的重定位，我們將在鏈接部分和《
動態符號鏈接的細節》一節介紹。
下面來看看ELF文件的主體內容，節區（Section)。ELF文件具有很大的靈活性，它通過文件頭組織整個文件的總體結構，通過節區表
(Section Headers Table)和程序頭（Program Headers Table或者叫段表)來分別描述可重定位文件和可執行文件。但不管是哪種類型，它們都需要它們的主體，即各種節區。在可重定位文件中，節區
表描述的就是各種節區本身；而在可執行文件中，程序頭描述的是由各個節區組成的段（Segment），以便程序運行時動態裝載器知道如何對它們進行內存映像，從而方便程序加載和運行。
下面先來看看
一些常見的節區，而關于這些節區(section)如何通過重定位構成成不同的段(Segments)，以及有哪些常規的段，我們將在鏈接部分進一步介紹。
可以通過readelf的-S參數查看ELF的節區。（建議一邊操作一邊看文檔，以便加深對ELF文件結構的理解）先來看看可重定位文件的節區信息，通過節區表來查看：
| Quote: |
|
$ gcc -c myprintf.c #默認編譯好myprintf.c，將產生一個可重定位的文件myprintf.o
$ readelf -S myprintf.o #通過查看myprintf.o的節區表查看節區信息
There are 11 section headers, starting at offset 0xc0:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 000018 00 AX 0 0 4
[ 2] .rel.text REL 00000000 000334 000010 08 9 1 4
[ 3] .data PROGBITS 00000000 00004c 000000 00 WA 0 0 4
[ 4] .bss NOBITS 00000000 00004c 000000 00 WA 0 0 4
[ 5] .rodata PROGBITS 00000000 00004c 00000e 00 A 0 0 1
[ 6] .comment PROGBITS 00000000 00005a 000012 00 0 0 1
[ 7] .note.GNU-stack PROGBITS 00000000 00006c 000000 00 0 0 1
[ 8] .shstrtab STRTAB 00000000 00006c 000051 00 0 0 1
[ 9] .symtab SYMTAB 00000000 000278 0000a0 10 10 8 4
[10] .strtab STRTAB 00000000 000318 00001a 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
$ objdump -d -j .text myprintf.o #這里是程序指令部分，用objdump的-d選項可以看到反編譯的結果，
#-j指定需要查看的節區
myprintf.o: file format elf32-i386
Disassembly of section .text:
00000000 <myprintf>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 08 sub $0x8,%esp
6: 83 ec 0c sub $0xc,%esp
9: 68 00 00 00 00 push $0x0
e: e8 fc ff ff ff call f <myprintf+0xf>
13: 83 c4 10 add $0x10,%esp
16: c9 leave
17: c3 ret
$ readelf -r myprintf.o #用-r選項可以看到有關重定位的信息，這里有兩部分需要重定位
Relocation section '.rel.text' at offset 0x334 contains 2 entries:
Offset Info Type Sym.Value Sym. Name
0000000a 00000501 R_386_32 00000000 .rodata
0000000f 00000902 R_386_PC32 00000000 puts
$ readelf -x .rodata myprintf.o #.rodata節區包含只讀數據，即我們要打印的hello, world!.
Hex dump of section '.rodata':
0x00000000 68656c6c 6f2c2077 6f726c64 2100 hello, world!.
$ readelf -x .data myprintf.o #沒有這個節區,.data應該包含一些初始化的數據
Section '.data' has no data to dump.
$ readelf -x .bss mmyprintf.o #也沒有這個節區，.bss應該包含一些未初始化的數據，程序默認初始為0
Section '.bss' has no data to dump.
$ readelf -x .comment myprintf.o #是一些注釋，可以看到是是GCC的版本信息
Hex dump of section '.comment':
0x00000000 00474343 3a202847 4e552920 342e312e .GCC: (GNU) 4.1.
0x00000010 3200 2.
$ readelf -x .note.GNU-stack myprintf.o #這個也沒有內容
Section '.note.GNU-stack' has no data to dump.
$ readelf -x .shstrtab myprintf.o #包括所有節區的名字
Hex dump of section '.shstrtab':
0x00000000 002e7379 6d746162 002e7374 72746162 ..symtab..strtab
0x00000010 002e7368 73747274 6162002e 72656c2e ..shstrtab..rel.
0x00000020 74657874 002e6461 7461002e 62737300 text..data..bss.
0x00000030 2e726f64 61746100 2e636f6d 6d656e74 .rodata..comment
0x00000040 002e6e6f 74652e47 4e552d73 7461636b ..note.GNU-stack
0x00000050 00 .
$ readelf -symtab myprintf.o #符號表，包括所有用到的相關符號信息，如函數名、變量名
Symbol table '.symtab' contains 10 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS myprintf.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 3
4: 00000000 0 SECTION LOCAL DEFAULT 4
5: 00000000 0 SECTION LOCAL DEFAULT 5
6: 00000000 0 SECTION LOCAL DEFAULT 7
7: 00000000 0 SECTION LOCAL DEFAULT 6
8: 00000000 24 FUNC GLOBAL DEFAULT 1 myprintf
9: 00000000 0 NOTYPE GLOBAL DEFAULT UND puts
$ readelf -x .strtab myprintf.o #字符串表，用到的字符串，包括文件名、函數名、變量名等。
Hex dump of section '.strtab':
0x00000000 006d7970 72696e74 662e6300 6d797072 .myprintf.c.mypr
0x00000010 696e7466 00707574 7300 intf.puts.
|
從上表可以看出，對于可重定位文件，會包含這些基本節區.text, .rel.text, .data, .bss, .rodata,
.comment, .note.GNU-stack, .shstrtab,
.symtab和.strtab。為了進一步理解這些節區和源代碼的關系，這里來看一看myprintf.c產生的匯編代碼。
| Quote: |
|
$ gcc -S myprintf.c
$ cat myprintf.s
.file "myprintf.c"
.section .rodata
.LC0:
.string "hello, world!"
.text
.globl myprintf
.type myprintf, @function
myprintf:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
subl $12, %esp
pushl $.LC0
call puts
addl $16, %esp
leave
ret
.size myprintf, .-myprintf
.ident "GCC: (GNU) 4.1.2"
.section .note.GNU-stack,"",@progbits
|
是不是可以從中看出可重定位文件中的那些節區和匯編語言代碼之間的關系？在上面的可重定位文件，可以看到有一個可重定位的節區，即.
rel.text，它標記了兩個需要重定位的項，.rodata和puts。這個節區將告訴編譯器這兩個信息在鏈接或者動態鏈接的過程中需要重定位，
具體如何重定位？將根據重定位項的類型，比如上面的R_386_32和R_386_PC32(關于這些類型的更多細節，請查看ELF手冊[6])。
到這里，對可重定位文件應該有了一個基本的了解，下面將介紹什么是可重定位，可重定位文件到底是如何被鏈接生成可執行文件和動態連接庫的，這個過程除了進行了一些符號的重定位外，還進行了哪些工作呢？
本節參考資料：
[1] 了解編譯程序的過程
http://9iyou.com/Program_Data/linuxunix-3125.htmlhttp://www.host01.com/article/server/00070002/0621409075078127.htm[2] C track: compiling C programs.
http://www.cs.caltech.edu/courses/cs11/material/c/mike/misc/compiling_c.html[3] Dissecting shared libraries
http://www.ibm.com/developerworks/linux/library/l-shlibs.html4、鏈接
開篇：重定位是將符號引用與符號定義進行鏈接的過程。因此鏈接是處理可重定位文件，把它們的各種符號引用和符號定義轉換為可執行文件中的合適信息(一般是虛擬內存地址)的過程。鏈接又
分為靜態鏈接和動態鏈接，前者是程序開發階段程序員用ld(gcc實際上在后臺調用了ld)靜態鏈接器手動鏈接的過程，而動態鏈接則是程序運行期間系
統調用動態鏈接器(ld-linux.so)自動鏈接的過程。比如，如果鏈接到可執行文件中的是靜態連接庫libmyprintf.a，那么.
rodata節區在鏈接后需要被重定位到一個絕對的虛擬內存地址，以便程序運行時能夠正確訪問該節區中的字符串信息。而對于puts，因為它是動態連接庫libc.so中定義的函數，所
以會在程序運行時通過動態符號鏈接找出puts函數在內存中的地址，以便程序調用該函數。在這里主要討論靜態鏈接過程，動態鏈接過程見《
動態符號鏈接的細節》。
靜態鏈接過程主要是把可重定位文件依次讀入，分析各個文件的文件頭，進而依次讀入各個文件的節區，并計算各個節區的虛擬內存位置，對一些需要重定位的符號
進
行處理，設定它們的虛擬內存地址等，并最終產生一個可執行文件或者是動態鏈接庫。這個鏈接過程是通過ld來完成的，ld在鏈接時使用了一個鏈接腳本
（linker script），
該鏈接腳本處理鏈接的具體細節。由于靜態符號鏈接過程非常復雜，特別是計算符號地址的過程，考慮到時間關系，相關細節請參考ELF手冊[6]。這里主要介
紹可重定位文件中的節區（節區表描述的）和可執行文件中段（程序頭描述的）的對應關系以及gcc編譯時采用的一些默認鏈接選項。
下面先來看看可執行文件的節區信息，通過程序頭（段表）來查看：
| Quote: |
|
$ readelf -S test.o #為了比較，先把test.o的節區表也列出
There are 10 section headers, starting at offset 0xb4:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 000024 00 AX 0 0 4
[ 2] .rel.text REL 00000000 0002ec 000008 08 8 1 4
[ 3] .data PROGBITS 00000000 000058 000000 00 WA 0 0 4
[ 4] .bss NOBITS 00000000 000058 000000 00 WA 0 0 4
[ 5] .comment PROGBITS 00000000 000058 000012 00 0 0 1
[ 6] .note.GNU-stack PROGBITS 00000000 00006a 000000 00 0 0 1
[ 7] .shstrtab STRTAB 00000000 00006a 000049 00 0 0 1
[ 8] .symtab SYMTAB 00000000 000244 000090 10 9 7 4
[ 9] .strtab STRTAB 00000000 0002d4 000016 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
$ gcc -o test test.o libmyprintf.o
$ readelf -l test #我們發現，test和test.o,libmyprintf.o相比，多了很多節區，如.interp和.init等
Elf file type is EXEC (Executable file)
Entry point 0x80482b0
There are 7 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4
INTERP 0x000114 0x08048114 0x08048114 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x0047c 0x0047c R E 0x1000
LOAD 0x00047c 0x0804947c 0x0804947c 0x00104 0x00108 RW 0x1000
DYNAMIC 0x000490 0x08049490 0x08049490 0x000c8 0x000c8 RW 0x4
NOTE 0x000128 0x08048128 0x08048128 0x00020 0x00020 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version
.gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata
.eh_frame
03 .ctors .dtors .jcr .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag
06
|
上表給出了可執行文件的如下幾個段(segment)，
PHDR: 給出了程序表自身的大小和位置，不能出現一次以上。
INTERP: 因為程序中調用了puts（在動態鏈接庫中定義），使用了動態連接庫，因此需要動態裝載器／鏈接器(ld-linux.so)
LOAD: 包括程序的指令，.text等節區都映射在該段，只讀(R)
LOAD: 包括程序的數據，.data, .bss等節區都映射在該段，可讀寫(RW)
DYNAMIC: 動態鏈接相關的信息，比如包含有引用的動態連接庫名字等信息
NOTE: 給出一些附加信息的位置和大小
GNU_STACK: 這里為空，應該是和GNU相關的一些信息
這里的段可能包括之前的一個或者多個節區，也就是說經過鏈接之后原來的節區被重排了，并映射到了不同的段，這些段將告訴系統應該如何把它加載到內存中。
從上表中，通過比較可執行文件(test)中擁有的節區和可重定位文件(test.o和myprintf.o)中擁有的節區后發現，鏈接之后多了一些之前沒有的節區，這些新的節區來自哪里？它們的作用是什么呢？先來通過gcc的-v參數看看它的后臺鏈接過程。
| Quote: |
|
$ gcc -v -o test test.o myprintf.o #把可重定位文件鏈接成可執行文件
Reading specs from /usr/lib/gcc/i486-slackware-linux/4.1.2/specs
Target: i486-slackware-linux
Configured
with: ../gcc-4.1.2/configure --prefix=/usr --enable-shared
--enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix
--enable-__cxa_atexit --disable-checking --with-gnu-ld --verbose
--with-arch=i486 --target=i486-slackware-linux
--host=i486-slackware-linux
Thread model: posix
gcc version 4.1.2
/usr/libexec/gcc/i486-slackware-linux/4.1.2/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../crt1.o
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../crti.o
/usr/lib/gcc/i486-slackware-linux/4.1.2/crtbegin.o
-L/usr/lib/gcc/i486-slackware-linux/4.1.2
-L/usr/lib/gcc/i486-slackware-linux/4.1.2
-L/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../../i486-slackware-linux/lib
-L/usr/lib/gcc/i486-slackware-linux/4.1.2/../../.. test.o myprintf.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/i486-slackware-linux/4.1.2/crtend.o
/usr/lib/gcc/i486-slackware-linux/4.1.2/../../../crtn.o
|
從上邊的演示看出，gcc在連接了我們自己的目標文件test.o和myprintf.o之外，還連接了crt1.o,crtbegin.o等額外的目標文件，難道那些新的節區就來自這些文件？
另外gcc在進行了相關配置(./configure)后，調用了collect2，卻并沒有調用ld，通過查找gcc文檔中和collect2相關的部
分發現collect2在后臺實際上還是去尋找ld命令的。為了理解gcc默認連接的后臺細節，這里直接把collect2替換成ld，并把一些路徑換成
絕對路徑或者簡化，得到如下的ld命令以及執行的效果。
| Quote: |
|
$ ld --eh-frame-hdr \
-m elf_i386 \
-dynamic-linker /lib/ld-linux.so.2 \
-o test \
/usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/i486-slackware-linux/4.1.2/crtbegin.o \
test.o myprintf.o \
-L/usr/lib/gcc/i486-slackware-linux/4.1.2
-L/usr/i486-slackware-linux/lib -L/usr/lib/ -lgcc --as-needed -lgcc_s
--no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed \
/usr/lib/gcc/i486-slackware-linux/4.1.2/crtend.o /usr/lib/crtn.o
$ ./test
hello, world!
|
不出我們所料，它完美的運行了。下面通過ld的手冊(man ld)來分析一下這幾個參數。
--eh-frame-hdr
要求創建一個.eh_frame_hdr節區(貌似目標文件test中并沒有這個節區，所以不關心它)。
-m elf_i386
這
里指定不同平臺上的鏈接腳本，可以通過--verbose命令查看腳本的具體內容，如ld -m elf_i386
--verbose，它實際上被存放在一個文件中(/usr/lib/ldscripts目錄下），你可以去修改這個腳本，具體如何做？請參考ld的手冊。
在后面我們將簡要提到鏈接腳本中是如何預定義變量的，以及這些預定義變量如何在我們的程序中使用。需要提到的是，如果不是交叉編譯，那么無須指定該選項。
-dynamic-linker /lib/ld-linux.so.2
指定動態裝載器/鏈接器，即程序中的INTERP段中的內容。動態裝載器/連接器負責連接有可共享庫的可執行文件的裝載和動態符號連接。
-o test
指定輸出文件，即可執行文件名的名字
/usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/i486-slackware-linux/4.1.2/crtbegin.o
鏈
接到test文件開頭的一些內容，這里實際上就包含了.init等節區。.init節區包含一些可執行代碼，在main函數之前被調用，以便進行一些初始化操
作，在C++中完成構造函數功能，更多細節請參考資料[9]
test.o myprintf.o
鏈接我們自己的可重定位文件
-L/usr/lib/gcc/i486-slackware-linux/4.1.2
-L/usr/i486-slackware-linux/lib -L/usr/lib/ -lgcc --as-needed -lgcc_s
--no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
鏈接libgcc庫和libc庫，后者定義有我們需要的puts函數
/usr/lib/gcc/i486-slackware-linux/4.1.2/crtend.o /usr/lib/crtn.o
鏈接到test文件末尾的一些內容，這里實際上包含了.fini等節區。.fini節區包含了一些可執行代碼，在程序退出時被執行，作一些清理工作，在C++中完成析構造函數功能。我們往往可以通過atexit來注冊那些需要在程序退出時才執行的函數。
對于crtbegin.o和crtend.o這兩個文件，貌似完全是用來支持C++的構造和析構工作的[9]，所以可以不鏈接到我們的可執行文件中，鏈接時把它們去掉看看，
| Quote: |
|
$
ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test
/usr/lib/crt1.o /usr/lib/crti.o test.o myprintf.o -L/usr/lib -lc
/usr/lib/crtn.o #后面發現不用鏈接libgcc，也不用--eh-frame-hdr參數
$ readelf -l test
Elf file type is EXEC (Executable file)
Entry point 0x80482b0
There are 7 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4
INTERP 0x000114 0x08048114 0x08048114 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x003ea 0x003ea R E 0x1000
LOAD 0x0003ec 0x080493ec 0x080493ec 0x000e8 0x000e8 RW 0x1000
DYNAMIC 0x0003ec 0x080493ec 0x080493ec 0x000c8 0x000c8 RW 0x4
NOTE 0x000128 0x08048128 0x08048128 0x00020 0x00020 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version
.gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata
03 .dynamic .got .got.plt .data
04 .dynamic
05 .note.ABI-tag
06
$ ./test
hello, world!
|
完全可以工作，而且發現.ctors(保存著程序中全局構造函數的指針數組),
.dtors（保存著程序中全局析構函數的指針數組）,.jcr（未知）,.eh_frame節區都沒有了，所以crtbegin.o和crtend.o應該包含了這些節區。
而對于另外兩個文件crti.o和crtn.o，通過readelf
-S查看后發現它們都有.init和.fini節區，如果我們不需要讓程序進行一些初始化和清理工作呢？是不是就可以不
鏈接這個兩個文件？試試看。
| Quote: |
|
$ ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test /usr/lib/crt1.o test.o myprintf.o -L/usr/lib/ -lc
/usr/lib/libc_nonshared.a(elf-init.oS): In function `__libc_csu_init':
(.text+0x25): undefined reference to `_init'
|
貌似不行，竟然有人調用了__libc_csu_init函數，而這個函數引用了_init。這兩個符號都在哪里呢？
| Quote: |
|
$ readelf -s /usr/lib/crt1.o | grep __libc_csu_init
18: 00000000 0 NOTYPE GLOBAL DEFAULT UND __libc_csu_init
$ readelf -s /usr/lib/crti.o | grep _init
17: 00000000 0 FUNC GLOBAL DEFAULT 5 _init
|
竟然是crt1.o調用了__libc_csu_init函數，而該函數卻引用了我們沒有鏈接的crti.o文件中定義的_init符號。這樣的話不鏈接
crti.o和crtn.o文件就不成了羅？不對吧，要不干脆不用crt1.o算了，看看gcc額外連接進去的最后一個文件crt1.o到底干了個啥子？
| Quote: |
|
$ ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test test.o myprintf.o -L/usr/lib/ -lc
ld: warning: cannot find entry symbol _start; defaulting to 00000000080481a4
|
這樣卻說沒有找到入口符號_start，難道crt1.o中定義了這個符號？不過它給默認設置了一個地址，只是個警告，說明test已經生成，不管怎樣先運行看看再說。
| Quote: |
|
$ ./test
hello, world!
Segmentation fault
|
貌似程序運行完了，不過結束時冒出個段錯誤？可能是程序結束時有問題，用gdb調試看看：
| Quote: |
|
$ gcc -g -c test.c myprintf.c #產生目標代碼, 非交叉編譯，不指定-m也可以鏈接成功，所以下面可以去掉-m參數
$ ld -dynamic-linker /lib/ld-linux.so.2 -o test test.o myprintf.o -L/usr/lib -lc
ld: warning: cannot find entry symbol _start; defaulting to 00000000080481d8
$ ./test
hello, world!
Segmentation fault
$ gdb ./test
...
(gdb) l
1 #include "test.h"
2
3 int main()
4 {
5 myprintf();
6 return 0;
7 }
(gdb) break 7 #在程序的末尾設置一個斷點
Breakpoint 1 at 0x80481bf: file test.c, line 7.
(gdb) r #程序都快結束了都沒問題，怎么會到最后出個問題呢？
Starting program: /mnt/hda8/Temp/c/program/test
hello, world!
Breakpoint 1, main () at test.c:7
7 }
(gdb) n #單步執行看看，怎么下面一條指令是0x00000001，肯定是程序退出以后出了問題
0x00000001 in ?? ()
(gdb) n #誒，當然找不到邊了，都跑到0x00000001了
Cannot find bounds of current function
(gdb) c #原來是這么回事，估計是return 0返回之后出問題了，看看它的匯編去。
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x00000001 in ?? ()
$ gcc -S test.c #產生匯編代碼
$ cat test.s #后面就這么幾條指令，難不成ret返回有問題，不讓它ret返回，把return改成_exit直接進入內核退出
...
call myprintf
movl $0, %eax
addl $4, %esp
popl %ecx
popl %ebp
leal -4(%ecx), %esp
ret
...
$ vim test.c
$ cat test.c #就把return語句修改成_exit了。
#include "test.h"
#include <unistd.h> /* _exit */
int main()
{
myprintf();
_exit(0);
}
$ gcc -g -c test.c myprintf.c
$ ld -dynamic-linker /lib/ld-linux.so.2 -o test test.o myprintf.o -L/usr/lib -lc
ld: warning: cannot find entry symbol _start; defaulting to 00000000080481d8
$ ./test #竟然好了，再看看匯編有什么不同
hello, world!
$ gcc -S test.c
$ cat test.s #貌似就把ret指令替換成了_exit函數調用，直接進入內核，然內核讓處理了，那為什么ret有問題呢？
...
call myprintf
subl $12, %esp
pushl $0
call _exit
...
$ gdb ./test #把代碼改回去（改成return 0;），再調試看看調用main函數返回時的下一條指令地址eip
...
(gdb) l
warning: Source file is more recent than executable.
1 #include "test.h"
2
3 int main()
4 {
5 myprintf();
6 return 0;
7 }
(gdb) break 5
Breakpoint 1 at 0x80481b5: file test.c, line 5.
(gdb) break 7
Breakpoint 2 at 0x80481bc: file test.c, line 7.
(gdb) r
Starting program: /mnt/hda8/Temp/c/program/test
Breakpoint 1, main () at test.c:5
5 myprintf();
(gdb) x/8x $esp #發現0x00000001剛好是之前我們調試時看到的程序返回后的位置，即eip，說明程序在初始化的時候
#這個eip就是錯誤的。為什么呢？因為我們根本沒有鏈接進來初始化的代碼，而是在編譯器自己給我們
#初始化了一個程序入口即00000000080481d8，也就是說，沒有任何人調用main,main不知道返回哪里去
#所以，我們直接讓main結束時進入內核調用_exit而退出則不會有問題
0xbf929510: 0xbf92953c 0x080481a4 0x00000000 0xb7eea84f
0xbf929520: 0xbf92953c 0xbf929534 0x00000000 0x00000001
|
通過上面的演示和解釋發現只要把return語句修改為_exit語句，程序即使不鏈接任何額外的目標代碼都可以正常運行（原因是不連接那些額外的文件時
相當于沒有進行初始化操作，如果在程序的最后執行ret匯編指令，程序將無法獲得正確的eip，從而無法進行后續的動作）。但是為什么會有“找不到
_start符號”的警告呢？通過readelf
-s查看crt1.o發現里頭有這個符號，并且crt1.o引用了main這個符號，是不是意味著會從_start進入main呢？是不是程序入口是
_start，而并非main呢？
先來看看剛才提到的鏈接器的默認鏈接腳本(ld -m elf_386
--verbose)，它告訴我們程序的入口(entry)是_start，而一個可執行文件必須有一個入口地址才能運行，所以這就是說明了為什么ld一
定要提示我們“_start找不到”，找不到以后就給默認設置了一個地址。
| Quote: |
|
$ ld --verbose | grep ^ENTRY #非交叉編譯，可不用-m參數；ld默認找_start入口，并不是main哦！
ENTRY(_start)
|
原來是這樣，程序的入口(entry)竟然不是main函數，而是_start。那干脆把匯編里頭的main給改掉算了，看行不行？
| Quote: |
|
$ cat test.c
#include "test.h"
#include <unistd.h> /* _exit */
int main()
{
myprintf();
_exit(0);
}
$ gcc -S test.c
$ sed -i -e "s#main#_start#g" test.s #把匯編中的main全部修改為_start，即修改程序入口為_start
$ gcc -c test.s myprintf.c
$ ld -dynamic-linker /lib/ld-linux.so.2 -o test test.o myprintf.o -L/usr/lib/ -lc #果然沒問題了 :-)
$ ./test
hello, world!
|
_start竟然是真正的程序入口，那在有main的情況下呢？為什么在_start之后能夠找到main呢？這個看看alert7大叔的"Before
main分析"[5]吧，這里不再深入介紹。總之呢，通過修改程序的return語句為_exit(0)和修改程序的入口為_start，我們的代碼不鏈接gcc默認鏈
接的那些額外的文件同樣可以工作得很好。并且打破了一個學習C語言以來的常識：main函數作為程序的主函數，是程序的入口，實際上則不然。
再補充一點內容，在ld的鏈接腳本中，有一個特別的關鍵字PROVIDE，由這個關鍵字定義的符號是ld的預定義字符，我們可以在C語言函數中擴展它們后直接使用。這些特別的符號可以通過下面的方法獲取，
| Quote: |
|
$ ld --verbose | grep PROVIDE | grep -v HIDDEN
PROVIDE (__executable_start = 0x08048000); . = 0x08048000 + SIZEOF_HEADERS;
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
_edata = .; PROVIDE (edata = .);
_end = .; PROVIDE (end = .);
|
這里面有幾個我們比較關心的，第一個是程序的入口地址__executable_start，另外三個是etext，edata，end，分別對應程序的
代碼段(text)、初始化數據(data)和未初始化的數據(bss)（可以參考資料[6]和man
etext），如何引用這些變量呢？看看這個例子。
Code:
[Ctrl+A Select All]
到這里，程序鏈接過程的一些細節都介紹得差不多了。在《動態符號鏈接的細節》中將主要介紹ELF文件的動態符號鏈接過程。
本節參考資料
[1] An beginners guide to compiling programs under Linux.
http://www.luv.asn.au/overheads/compile.html
[2] gcc manual
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/
[3] A Quick Tour of Compiling, Linking, Loading, and Handling Libraries on Unix
http://efrw01.frascati.enea.it/Software/Unix/IstrFTU/cern-cnl-2001-003-25-link.html
[4] Unix 目標文件初探
http://www.ibm.com/developerworks/cn/aix/library/au-unixtools.html
[5] Before main()分析
http://www.xfocus.net/articles/200109/269.html
[6] A Process Viewing Its Own /proc/<PID>/map Information
http://www.linuxforums.org/forum/linux-kernel/51790-process-viewing-its-own-proc-pid-map-information.html
by falcon <zhangjinw@gmail.com>
平時在Linux下寫代碼，直接用"gcc -o out
in.c"就把代碼編譯好了，但是這后面到底做了什么事情呢？如果學習過編譯原理則不難理解，一般高級語言程序編譯的過程莫過于：預處理、編譯、匯編、鏈
接。gcc在后臺實際上也經歷了這幾個過程，我們可以通過-v參數查看它的編譯細節，如果想看某個具體的編譯過程，則可以分別使用-E,-S,-c和-
O，對應的后臺工具則分別為cpp,cc1,as,ld。下面我們將逐步分析這幾個過程以及相關的內容，諸如語法檢查、代碼調試、匯編語言等。
1、預處理
開篇簡述：預處理是C語言程序從源代碼變成可執行程序的第一步，主要是C語言編譯器對各種預處理命令進行處理，包括頭文件的包含、宏定義的擴展、條件編譯的選擇等。
以前沒怎么“深入”預處理，腦子對這些東西總是很模糊，只記得在編譯的基本過程（詞法分析、語法分析）之前還需要對源代碼中的宏定義、文件包含、條件編譯
等命令進行處理。這三類的指令很常見，主要有#define, #include和#ifdef ...
#endif，要特別地注意它們的用法。（更多預處理的指令請查閱相關資料）
#define除了可以獨立使用以便靈活設置一些參數外，還常常和#ifdef ...
#endif結合使用，以便靈活地控制代碼塊的編譯與否，也可以用來避免同一個頭文件的多次包含。關于#include貌似比較簡單，通過man找到某個
函數的頭文件，copy進去，加上<>就okay。這里雖然只關心一些技巧，不過預處理還是蘊含著很多潛在的陷阱（可參考<C
Traps & Pitfalls>），我們也需要注意的。下面僅介紹和預處理相關的幾個簡單內容。
打印出預處理之后的結果：gcc -E hello.c
這樣我們就可以看到源代碼中的各種預處理命令是如何被解釋的，從而方便理解和查錯。
實際上gcc在這里是調用了cpp的(雖然我們通過gcc的-v僅看到cc1)，cpp即The C Preprocessor，主要用來預處理宏定義、文件包含、條件編譯等。下面介紹它的一個比較重要的選項-D。
在命令行定義宏：gcc -Dmacro hello.c
這個等同于在文件的開頭定義宏，即#define maco，但是在命令行定義更靈活。例如，在源代碼中有這些語句。
#ifdef DEBUG
printf("this code is for debugging\n");
#endif
如果編譯時加上-DDEBUG選項，那么編譯器就會把printf所在的行編譯進目標代碼，從而方便地跟蹤該位置的某些程序狀態。這樣-DDEBUG就可以當作一個調試開關，編譯時加上它就可以用來打印調試信息，發布時則可以通過去掉該編譯選項把調試信息去掉。
本節參考資料：
[1] C語言教程第九章:預處理
http://www.bc-cn.net/Article/kfyy/cyy/jc/200409/9.html
[2] 更多
http://www.hemee.com/kfyy/c/6626.html
http://www.91linux.com/html/article/program/cpp/20071203/8745.html
http://www.janker.org/bbs/programmer/2006-10-13/327.html
2、編譯（翻譯）
開篇簡要：編譯之前，C語言編譯器會進行詞法分析、語法分析(-fsyntax-only)，接著會把源代碼翻譯成中間語言，即匯編語言。如果想看到這個
中間結果，可以用-S選項。需要提到的是，諸如shell等解釋語言也會經歷一個詞法分析和語法分析的階段，不過之后并不會進行“翻譯”，而是“解釋”，
邊解釋邊執行。
把源代碼翻譯成匯編語言，實際上是編譯的整個過程中的第一個階段，之后的階段和匯編語言的開發過程沒有什么區別。這個階段涉及到對源代碼的詞法分析、語法檢查（通過-std指定遵循哪個標準），并根據優化(-O)要求進行翻譯成匯編語言的動作。
如果僅僅希望進行語法檢查，可以用-fsyntax-only選項；而為了使代碼有比較好的移植性，避免使用gcc的一些特性，可以結合-std和-
pedantic（或者-pedantic-erros)選項讓源代碼遵循某個C語言標準的語法。這里演示一個簡單的例子。
| Quote: |
|
$ cat hello.c
#include <stdio.h>
int main()
{
printf("hello, world\n")
return 0;
}
$ gcc -fsyntax-only hello.c
hello.c: In function ‘main’:
hello.c:5: error: expected ‘;’ before ‘return’
$ vim hello.c
$ cat hello.c
#include <stdio.h>
int main()
{
printf("hello, world\n");
int i;
return 0;
}
$ gcc -std=c89 -pedantic-errors hello.c #默認情況下，gcc是允許在程序中間聲明變量的，但是turboc就不支持
hello.c: In function ‘main’:
hello.c:5: error: ISO C90 forbids mixed declarations and code
|
語法錯誤是程序開發過程中難以避免的錯誤（人的大腦在很多條件下都容易開小差），不過編譯器往往能夠通過語法檢查快速發現這些錯誤，并準確地告訴你語法錯
誤的大概位置。因此，作為開發人員，要做的事情不是“恐慌”（不知所措），而是認真閱讀編譯器的提示，根據平時積累的經驗（最好在大腦中存一份常見語法錯
誤索引，很多資料都提供了常見語法錯誤列表，如<C
Traps&Pitfalls>和最后面的參考資料[12]也列出了很多常見問題）和編輯器提供的語法檢查功能（語法加亮、括號匹配提示
等）快速定位語法出錯的位置并進行修改。
語法檢查之后就是翻譯動作，gcc提供了一個優化選項-O，以便根據不同的運行平臺和用戶要求產生經過優化的匯編代碼。例如，
| Quote: |
|
$ gcc -o hello hello.c #采用默認選項，不優化
$ gcc -O2 -o hello2 hello.c #優化等次是2
$ gcc -Os -o hellos hello.c #優化目標代碼的大小
$ ls -S hello hello2 hellos #可以看到，hellos比較小,hello2比較大
hello2 hello hellos
$ time ./hello
hello, world
real 0m0.001s
user 0m0.000s
sys 0m0.000s
$ time ./hello2 #可能是代碼比較少的緣故，執行效率看上去不是很明顯
hello, world
real 0m0.001s
user 0m0.000s
sys 0m0.000s
$ time ./hellos #雖然目標代碼小了，但是執行效率慢了些
hello, world
real 0m0.002s
user 0m0.000s
sys 0m0.000s
|
根據上面的簡單演示，可以看出gcc有很多不同的優化選項，主要看用戶的需求了，目標代碼的大小和效率之間貌似存在一個“糾纏”，需要開發人員自己權衡。
下面我們通過-S選項來看看編譯出來的中間結果，匯編語言，還是以之前那個hello.c為例。
| Quote: |
|
$ gcc -S hello.c #默認輸出是hello.s，可自己指定，輸出到屏幕-o -，輸出到其他文件-o file
$ cat hello.s
cat hello.s
.file "hello.c"
.section .rodata
.LC0:
.string "hello, world"
.text
.globl main
.type main, @function
main:
leal 4(%esp), %ecx
andl $-16, %esp
pushl -4(%ecx)
pushl %ebp
movl %esp, %ebp
pushl %ecx
subl $4, %esp
movl $.LC0, (%esp)
call puts
movl $0, %eax
addl $4, %esp
popl %ecx
popl %ebp
leal -4(%ecx), %esp
ret
.size main, .-main
.ident "GCC: (GNU) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)"
.section .note.GNU-stack,"",@progbits
|
不知道看出來沒？和我們在課堂里學的intel的匯編語法不太一樣，這里用的是AT&T語法格式。如果之前沒接觸過AT&T的，可以看看
參考資料[2]。如果想學習Linux下的匯編語言開發，從下一節開始哦，下一節開始的所有章節基本上覆蓋了Linux下匯編語言開發的一般過程，不過這
里不介紹匯編語言語法。
這里需要補充的是，在寫C語言代碼時，如果能夠對編譯器比較熟悉（工作原理和一些細節）的話，可能會很有幫助。包括這里的優化選項(有些優化選項可能在匯
編時采用)和可能的優化措施，例如字節對齊(可以看看這本書"Linux_Assembly_Language_Programming"的第六小節)、
條件分支語句裁減(刪除一些明顯分支)等。
本節參考資料
[1] Guide to Assembly Language Programming in Linux(pdf教程，社區有下載)
http://oss.lzu.edu.cn/modules/wfdownloads/singlefile.php?cid=5&lid=94
[2] Linux匯編語言開發指南（在線）：
http://www.ibm.com/developerworks/cn/linux/l-assembly/index.html
[3] PowerPC 匯編
http://www.ibm.com/developerworks/cn/linux/hardware/ppc/assembly/index.html
[4] 用于 Power 體系結構的匯編語言
http://www.ibm.com/developerworks/cn/linux/l-powasm1.html
[5] Linux Assembly HOWTO
http://mirror.lzu.edu.cn/tldp/HOWTO/Assembly-HOWTO/
[6] Linux 中 x86 的內聯匯編
http://www.ibm.com/developerworks/cn/linux/sdk/assemble/inline/index.html
[7] Linux Assembly Language Programming
http://mirror.lzu.edu.cn/doc/incoming/ebooks/linux-unix/Linux_EN_Original_Books
by falcon<zhangjinw@gmail.com>
2008-02-22
程序開發過程中，源代碼的編輯主要是為了實現算法，結果則是一些可閱讀的、便于檢錯的、可移植的...文本文件。如何產生一份良好的源代碼文件，這不僅需要一些良好的編輯工具，還需要開發人員養成良好的編程修養[3][4]。
Linux下有很多優秀的程序編輯工具，包括專門的文本編輯器和一些集成開發環境(IDE)中提供的編輯工具，前者的代表作有vim和emacs，后者的代表作則有Eclipse，Kdevelope,Anjuta等，這里主要介紹VIM的基本使用和一些基本配置。
通過VIM進行文本編輯的一般過程（如附圖二）包括：文件的打開、編輯、保存、關閉，而編輯則包括插入新內容、替換已有內容、查找內容，還包括復制、粘貼、刪除等基本操作。
打開文件
在命令行下輸入"vim+文件名"即可打開一個新的文件并進入VIM的“編輯模式”。編輯模式可以切換到命令模式（按下字符:）和插入模式（按下字母 a/A/i/I/o/O/s/S/c/C等或者Insert鍵）。編輯模式下，VIM會把鍵盤輸入解釋成VIM的編輯命令，以便實現諸如字符串查找(按下字母/)、文本復制（按下字母yy）、粘貼（按下字母pp）、刪除（按下字母d等）、替換(s)等各種操作。當按下 a/A/i/I/o/O/s/S/c/C等字符時，VIM先執行這些字符對應的命令動作（比如移動光標到某個位置，刪除某些字符），然后進入插入模式；進入插入模式后可以通過按下ESC鍵或者是CTRL+C返回到編輯模式，當然，在編輯模式下輸入冒號":"后可進入命令模式，通過它可以完成一些復雜的編輯功能，比如進行正則表達式匹配替換，執行shell命令等。實際上，無論是插入模式還是命令模式都是編輯模式的一種。而編輯模式卻并不止它們兩個，還有字符串查找、刪除、替換等。需要提到的是，如果在編輯模式按下字母v/V或者是CTRL+V，可以用光標選擇一片代碼，進而結合命令模式對這一片代碼進行特定的操作。
編輯文件
打開文件以后即可進入編輯模式，這時可以進行各種編輯操作，包括插入、復制、刪除、替換字符。其中兩種比較重要的模式經常被“獨立”出來，即上面提到的插入模式和命令模式。
保存文件
在退出之前需切換到命令模式，輸入命令w以便保存各種編輯操作，如果想取消某種操作，可以用u命令。如果打開vim編輯器時沒有設定文件名，那么在按下w命令時會提示沒有文件名，此時需要在w命令后加上需要保存的文件名。
退出
保存好內容后就可退出，只需在命令模式下鍵入字符q。如果對文件內容進行了編輯，卻沒有保存，那么VIM會提示你保存內容，如果不想保存之前的編輯動作，那么可按下字符q并且在之后跟上一個感嘆號!，這樣會強制退出，不保存最近的內容變更。
這里需要著重提到的是VIM的命令模式，它是VIM擴展各種新功能的接口，用戶可以通過它啟用和撤銷某個功能，開發人員則可通過它為用戶提供新的功能。下面主要介紹通過命令模式這個接口定制VIM以便我們更好地進行源代碼的編輯（對于其他的內容建議看看參考資料中提到的VIM的官方教程和VIM實用技術序列，以及其他網友總結的VIM使用技巧等）。
這里先提一下編碼風格。剛學習編程時，代碼寫得很“難看”（不方便閱讀，不方便檢錯，看不出任何邏輯結構），常常導致心情不好，而且排錯也很困難，所以逐漸意識到代碼編寫需要規范，即養成良好的編碼風格，如果換成俗話，那就是代碼的排版，讓代碼好看一些。雖說“編程的“（高雅一些則稱開發人員）不一定懂藝術，不過這個應該不是“搞藝術的”（高雅一些應該是文藝工作人員）的特權，而是我們應該具備的專業素養。在Linux下，比較流行的“行業”風格有KR的編碼風格、gnu的編碼風格、linux內核的編碼風格（基于KR的，縮進是8個空格）等，它們都可以通過indent命令格式化，對應的選項分別是- kr,-gnu,-kr -i8。下面演示用indent把代碼格式化成上面的三種風格。
| Quote: |
|
$ vim test.c
$ cat test.c //這樣糟糕的編碼風格看者會讓人想“哭”，太難閱讀啦。
cat test.c
/* test.c -- a test program for using indent */
#include<stdio.h>
int main(int argc, char *argv[])
{
int i=0;
if (i != 0) {i++; }
else {i--; };
for(i=0;i<5;i++)j++;
printf("i=%d,j=%d\n",i,j);
return 0;
}
$ indent -kr test.c
$ cat test.c //好看多了
/* test.c -- a test program for using indent */
#include<stdio.h>
int main(int argc, char *argv[])
{
int i = 0;
if (i != 0) {
i++;
} else {
i--;
};
for (i = 0; i < 5; i++)
j++;
printf("i=%d,j=%d\n", i, j);
return 0;
}
$ indent -gnu test.c
$ cat test.c //感覺不如kr的風格，處理if語句時增加了代碼行，卻并沒明顯改進效果
/* test.c -- a test program for using indent */
#include<stdio.h>
int
main (int argc, char *argv[])
{
int i = 0;
if (i != 0)
{
i++;
}
else
{
i--;
};
for (i = 0; i < 5; i++)
j++;
printf ("i=%d,j=%d\n", i, j);
return 0;
}
|
從演示中可看出編碼風格真的很重要，但是如何養成良好的編碼風格呢？經常練習，遵守某個編碼風格，一如既往。不過這還不夠，如果沒有一個好編輯器，習慣也很難養成。而VIM提供了很多輔助我們養成良好編碼習慣的功能，這些都通過它的命令模式提供。現在分開介紹幾個功能；
語法加“靚”（亮） :sytax on
自動縮進寬度（需要set cin才有用）：set sw=8
TAB寬度：set ts=8
顯示行號；set number
括號自動匹配；set sm
C語言自動縮進：set cin
這幾個對代碼編寫來說非常有用，可以考慮把它們全部寫到~/.vimrc文件(vim啟動的時候會去執行這個文件里頭的內容)中，如；
| Quote: |
|
$ vim ~/.vimrc
$ cat ~/.vimrc
:set number
:set sw=8
:set ts=8
:set sm
:set cin
:syntax on
:set textwidth=70
:set mouse=a
:set encoding=utf-8
:set fileencoding=chinese
:set fileencodings=ucs-bom, utf-8, chinese
:set ambiwidth=double
nmap <F2> :nohlsearch <CR>
:abbr #b /***************************************************************************************
:abbr #e ***************************************************************************************/
|
需要補充的幾個技巧有；
在編輯模式下，可通過gqap命令對注釋自動斷行（每行字符個數可通過命令模式下的"set textwidth=個數"設定）
命令模式下輸入數字可以直接跳到指定行，也可在打開文件時用“vim +數字 文件名”實現相同的功能。
命令模式下的TOhtml命令可把C語言輸出為html文件，結合syntax on，可產生比較好的web page把代碼發布出去。
先切換到可視模式（編輯模式下按字母v可切換過來），用光標選中一片代碼，然后通過命令模式下的命令“s#^#//#g"把某一片代碼給注釋掉，這非常方便調試某一片代碼的功能。
命令模式下的”set paste“可解決復制本來已有縮進的代碼的自動縮進問題，后可執行”set nopaste“恢復自動縮進。
為了使用最新的vim特性，可用"set nocp"取消與老版本的vi的兼容。
如發現變量命名不好，想在整個代碼中修改，可在命令模式下用"%s#old_variable#new_variable#g"全局替換。替換的時注意變量名是其他變量一部分的情況。
如果想把縮進和TAB鍵替換成空格，可考慮設置expandtab，即“set et”，如果要把以前編寫的代碼中的縮進和TAB鍵都替換掉，可以用retab。
為實現關鍵字補全，輸入一部分字符后，按下CTRL+P即可。比如先輸入prin，然后按下CTRL+P就可以補全了。
如果想在在編輯模式下查看Linux手冊，可把光標定位到在某個函數，按下Shift+k就可以調出man，很有用。
刪除空行，在命令模式下輸入g/^$/d，前面g命令是擴展到全局，中間是匹配空行，后面d命令是執行刪除動作。用替換也可以實現，鍵入%s#^\ n##g，意思是把所有以換行開頭的行全部替換為空。類似地，如果要把多個空行轉換為一個可以輸入g/^\n$/d或者%s#^\n$##g。
注意使用一些有用的插件，比如ctags, cscope等，可以提高代碼閱讀、分析的效率。特別是open source的東西。
更多的技巧可以看看資料[2],[6],[7]。
實際上，在源代碼編寫時還有很多需要培養的“素質”，例如源文件的開頭注釋、函數的注釋，變量的命名等。這方面建議看看參考資料里的編程修養、內核編碼風格、網絡上流傳的《華為編程規范》，以及<C Traps & Pitfalls>等。
參考的資料：
[1] VIM官方教程，在命令行下鍵入vimtutor即可
[2] IBM developerworks 中國，VIM實用技術序列
實用技巧，http://www.ibm.com/developerworks/cn/linux/l-tip-vim1/
常用插件，http://www.ibm.com/developerworks/cn/linux/l-tip-vim2/
定制VIM，http://www.ibm.com/developerworks/cn/linux/l-tip-vim3/
[3] 編程修養
http://oss.lzu.edu.cn/modules/newbb/viewtopic.php?topic_id=126&forum=13
[4] 內核編碼風格
Document/codingstyle
[5] Linux C編程(主要介紹了一些簡單的技巧)
http://blog.ednchina.com/brucedeng/4695/message.aspx
[6] vim配置，配置得當可極大方便編程等工作
http://oss.lzu.edu.cn/blog/article.php?tid_1398.html
[7] VIM高級命令集錦
http://oss.lzu.edu.cn/modules/newbb/viewtopic.php?topic_id=830&forum=6
[8] C Traps & Pitfalls(英文版，不過比較簡單呢）
http://oss.lzu.edu.cn/modules/wfdownloads/singlefile.php?cid=6&lid=64
by falcon<zhangjinw@gmail.com>
2008-03-01
到今天，關于"Linux下C語言開發過程"的一個簡單視圖總算粗略的完成了，從寒假之前的一段時間到現在過了將近一個月左右吧。寫這個主題的目的源自
“shell編程范例之進程操作”，當我寫到“shell編程范例之進程操作”這一節時，“突然”對進程的由來、本身和去向感到“迷惑不解”。所以想著好
好花些時間來弄清楚它們，現在發現，這個由來就是這里的程序開發過程，進程來自一個普通的文本文件，在這里是C語言程序，C語言程序經過編輯、預處理、編
譯、匯編、鏈接、執行而成為一個進程；而進程本身呢？當一個可執行文件被執行以后，有了exec調用，被程序解釋器映射到了內存中，有了它的內存映像；而
進程的去向呢？通過不斷的執行指令和內存映像的變化，進程完成著各項任務，等任務完成以后就可以退出了(exit)。
這樣一份視圖實際上是在寒假之前繪好的，你可以從附件中看到它；不過到現在才明白背后的很多細節。這些細節就是下面的這些blogs，你可以對照“視圖”來閱讀它們。
1、把VIM打造成源代碼編輯器（源代碼編輯過程：用VIM編輯代碼的一些技巧）
2、GCC編譯的背后 第一部分：預處理和編譯 第二部分：匯編和鏈接（編譯過程：預處理、編譯、匯編、鏈接）
3、程序執行的那一剎那 （執行過程：當我們從命令行輸入一個命令之后）
4、進程的內存映像 （進程加載過程：程序在內存里是個什么樣子）
5、動態符號鏈接的細節（動態鏈接過程：函數puts/printf的地址在哪里）
6、代碼測試、調試與優化小結（程序開發過后：內存溢出了嗎？有緩沖區溢出？代碼覆蓋率如何測試呢？怎么調試匯編代碼？有哪些代碼優化技巧和方法呢？）
7、 8、進程和進程的基本操作（關于進程本身的相關操作，主要是介紹了一些shell命令）
需要補充的是，“高等數學”(higher mathematics)、“線性代數”(linear algebra)、“數據結構”(data
structure)、“數學建模”(mathematical modeling)、“設計模式”(design
pattern)、“算法”(algorithm)、“離散數學”(discrete mathematics)、“數學分析”(
mathematical analysis)等應該是程序設計必備的一些知識，在掌握相關工具的同時，這些相關的理論課程也需要很好的熟悉。
歡迎大家一起交流和探討。
PS: 因為時間關系，很多blog都寫得比較倉促，里頭有錯別字甚至是語義表達不清晰的地方，敬請原諒，我會逐步花時間進行檢查的。
推薦資料
[1] mathematical modeling
http://jpkc.nwu.edu.cn/sxjm/yxal.htm
[2] design pattern
[3] algorithm
http://oss.lzu.edu.cn/blog/blog.php?/do_showone/tid_338.html
引自 http://oss.lzu.edu.cn/blog/blog.php?do_showone/tid_62.html
剛學linux的時候，有些東西不大熟悉，非常惱火
為了脫離這話總困境，把自己遇到并解決的一些常用命令行操作集中寫到這里
1，如何刪除非空目錄？
用rmdir嗎？不是，而是
＃rm [your directory] -rf
意思是強制刪除該目錄，以及該目錄下所有文件，試試，肯定奏效，呵呵
不過不要隨便用，毫無提示就會刪除掉的
而rmdir只能刪除空目錄哦
另外，如果不強制刪除，只用
＃rm [your directory] -r
2，壓縮－解壓縮命令大全
tar.gz這個比較常見
解壓：tar zxvf FileName.tar.gz
壓縮：tar zcvf FileName.tar.gz DirName
還在為面對一大堆的壓縮文件無法解壓縮而煩惱嗎？
這里有比較全面的信息哦
http://www.chinaitlab.com/www/techspecial/tar/
3，如何用命令行創建和刪除文件名開頭為"-"的文件？
讓我們來創建一個這樣的文件“-test”
#touch -test
touch:日期格式 "est" 無效
#touch -- -test
#rm -test
rm:無效選項 --t
請嘗試執行"rm --help"來獲取更多幫助
#rm -- test
呵呵，是不是發現，只有加了"--"才可以正常操作阿
4，如果，我在鍵入ls命令以后只想顯示文件的部分信息，我該怎么辦呢？
也許你會查幫助ls --help
可是那么多的組合確實是讓人煩惱
不過先在不用煩惱拉
因為我們有gawk
看看這個:ls -l | gawk '{printf $9}'
看看輸出什么出來拉
是不是只有文件名拉
要是我還要別的呢，那就在printf后面再加一個$x(x為1到9之間的字符哦)
呵呵，其實gawk是一個腳本語言哦，功能非常強大，有興趣看看相關的參考書去拉
5，有個好東西，可以對linux服務進行相關的操作
chkconf
6，用rpm命令安裝和卸載軟件
RPM共有10種基本的模式：它們是安裝、查詢、驗證、刪除等。
安裝模式： rpm –i [安裝選項] <軟件包>
查詢模式： rpm –q [查詢選項]
驗證模式： rpm –V 或 –verify [驗證選項]
刪除模式： rpm –e <軟件包>
7，tee命令
這個命令的強大指處在于它會從標準輸入設備讀取數據，將其內容輸出到標準輸出設備,同時保存成文件。
例如，我們想把一個文件inputfile的內容即輸出到終端上也保存成outputfile1,outputfile2，那么我們就可以這么來弄：
| Quote: |
|
cat inputfile | tee outputfile1 outputfile2
|
參考資料：
http://jkwx007.blogchina.com/2514993.html
http://jordi.blogbus.com/logs/2004/10/452282.html
http://bbs.3671041.com/dispbbs.asp?boardid=9&id=747&star=1&page=1
http://www.knowsky.com/print.asp?id=18403
來源：http://www.chinaunix.net/jh/24/628479.html
引用：一、用戶登陸進入系統后的系統環境變量：
$HOME 使用者自己的目錄
$PATH 執行命令時所搜尋的目錄
$TZ 時區
$MAILCHECK 每隔多少秒檢查是否有新的信件
$PS1 在命令列時的提示號
$PS2 當命令尚未打完時，Shell 要求再輸入時的提示號
$MANPATH man 指令的搜尋路徑
二、特殊變量：
$0 這個程序的執行名字
$n 這個程序的第n個參數值，n=1..9
$* 這個程序的所有參數
$# 這個程序的參數個數
$$ 這個程序的PID
$! 執行上一個指令的PID
$? 執行上一個指令的返回值
三、shell中的變元：
* 任意字符串
? 一個任意字符
[abc] a, b, c三者中之一
[a-n] 從a到n的任一字符
四、幾個特殊字符表示
\b 退回
\c 打印一行時沒有換行符 這個我們經常會用到
\f 換頁
\r 回車
\t 制表
\v 垂直制表
\\ 反斜線本身
五、判斷文件的屬性
格式：-操作符 filename
-e 文件存在返回1， 否則返回0
-r 文件可讀返回1,否則返回0
-w 文件可寫返回1,否則返回0
-x 文件可執行返回1,否則返回0
-o 文件屬于用戶本人返回1, 否則返回0
-z 文件長度為0返回1, 否則返回0.
-f 文件為普通文件返回1, 否則返回0
-d 文件為目錄文件時返回1, 否則返回0
六、測試字符串
字符串1 = 字符串2 當兩個字串相等時為真
字符串1 != 字符串2 當兩個字串不等時為真
-n 字符串 當字符串的長度大于0時為真
-z 字符串 當字符串的長度為0時為真
字符串 當串字符串為非空時為真
七、測試兩個整數關系
數字1 -eq 數字2 兩數相等為真
數字1 -ne 數字2 兩數不等為真
數字1 -gt 數字2 數字1大于數字2為真
數字1 -ge 數字2 數字1大于等于數字2為真
數字1 -lt 數字2 數字1小于數字2為真
數字1 -le 數字2 數字1小于等于數字2為真
八、邏輯測試
-a 與
-o 或
! 非
今天介紹shell特殊字符的引用
===============================
shell中的特殊字符有
1、$ 美元符
2、\ 反斜杠
3、` 反引號
4、" 雙引號
5、< ,>,*,?,[,]
下面我一一舉列說明
一、$符號
1、echo $? 顯示的是上一條指令退出狀態
2、echo "$?" 效果同上
3、echo '$?' 顯示的是$?
4、echo \$? 顯示的是$?
5、echo "\$?" 顯示的是$?
大家可能已經看出 $符號在雙引號中具有特殊意義 雙引號對$符號不起作用
而單引號可以將特殊字符的的特殊意義屏蔽掉，使其能顯示為字符本身，反斜
杠也可以將特殊字符的特殊含義屏蔽掉，使特殊字符失去特殊含義。
二、\ 反斜杠
反斜杠的作用是將特殊符號字符的特殊含義屏蔽掉，使其還是原字符
A＝1234
echo \$A 顯示為$A 如果不加\將顯示為1234
echo \` 顯示為`
echo \" 顯示為雙引號
echo \\ 顯示為\
三、` 反引號
反引號的功能是命令替換，將反引號中的字符串做為命令來執行，我們在用shell編程時經常用的到 將系統命令的執行結果賦給一個變量
A=`date`
echo $A 顯示的不是date而是當時的時間串
比如有一文件A的內容如下
ABCDEFG
1234456
abcdefg
B=`cat A|grep 234` # 檢索文件A中含有字符串234的行
echo $B 將顯示為1234456
echo "$B" 將顯示為什么？
echo "\$B" 將顯示為什么？讀者自己試試
四、" 雙引號
在系統中有些特殊字符，為避免引用這些特殊字符 往往用雙引號或單引號將這些特殊字符引起來，使其不具有特殊含義。
但有一部分特殊字符在引號中還是具有特殊含義，用雙引號引起來是不起作用的。本文中所列的前四個特殊字符在雙引號中還是特殊字符。為了使其不具有特殊含義一是用單引號引進來二是用\反斜線使其失去作用。
比如我們想原樣輸出這些特殊字符
echo """
echo "$"
echo "\"
echo "`"
以上不是你所期望的結果，因為雙引號對它們不起作用，你只能這樣才能輸出這些特殊字符的原形
echo '"'
echo '$'
echo '\'
echo '`'
或
echo "\""
echo "\$"
echo "\\"
echo "\`"
將分別顯示為 " $ \ `
五、其它特殊字符
大家注意到 除了前四個特殊字符外 我將其它的特殊字符都放在一塊，這是因為前四個特殊字符在雙引號中還是具有特殊含義，所以單獨拿出來講，除此以外的特殊字符如果你要輸出這些特殊字符的原形，你就可以用雙引號或單引號引起來使其失去特殊含義。
< ,>,*,?,[,]對shell有特殊含義 但你可以用雙引號引起來輸入這些原形
講了這么多大家是不是已經注意到所有的特殊字符在單引號中失去特殊含義，如果你要輸出特殊字符原形但又記不清那些特殊字符在雙引號中不能輸出原形，建議你干脆用單引號引起來。
今天介紹條件測試語句
一、if 條件語句
格式：
if 條件表達式
then #當條件為真時執行以下語句
命令列表
else #為假時執行以下語句
命令列表
fi
if 語句也可以嵌套使用
if 條件表達式1
then
if 條件表達式2
then
命令列表
else
if 條件表達式3
then
命令列表
else
命令列表
fi
fi
else
命令列表
fi
你可以進行多層嵌套 一個if語句一定要跟一個fi 表示該層條件結束 否則會造成語法錯誤
結合前面講的 舉例如下：
這里先講一個條件語句中用到的命令test 表示測試test后面的條件是否為真
if test -f "$1"
then
lpr $1
else
if test -d "$1"
then
cd $1
lpr $1
else
echo "$1不是文件或目錄"
fi
fi
以上的例子還可以改成如下所示
if test -f "$1"
then
lpr $1
elif test -d "$1" #elif 同else if
then
(cd $1;lpr $1)
else
echo "$1不是文件或目錄"
fi
以上的例子不知您是否看懂是什么意思嗎？
假如我們現在將這個例子保存為prfile
chmod +x prfile
執行剛才的程序
./prfile aaa
這個例子是檢查你的輸入的參數是否是一個文件 如果是就打印 如果是一個目錄 先轉目錄再打印 如果即不是文件也不是目錄給出提示
二、多重條件測試語句case
格式：
case 字串 in
模式) 命令列表;;
模式) 命令列表;;
....
esac
多重條件語句是以case 開始以esac結束 中間可以有多個條件列表 功能是測試字串和和里面的模式有沒有匹配的,有就執行里面的命令列表 模式也可以是*號 表示任意字串，每個模式里面的最后要心;;雙引號結束，否則會發生語法錯誤。
現舉例如下：
case $1 in
*.c)
cc $1
;;
*.txt)
lpr $1
;;
*)
echo "未知的類型"
esac
假如將以上內容保存在文件abc中
chmod +x abc
執行 ./abc a.c 將會對文件a.c進行編譯
執行 ./abc readme.txt 將會把文件通過打印機
假如我將以上內容改一下，你是否會知道它的執行結果？
case $1 in
*)
cc $1
;;
*.txt)
lpr $1
;;
*.c)
echo "未知的類型"
esac
今天介紹循環語句
一. while 循環
while 命令格式
while 條件表
do
命令表
done
執行過程
shell首先執行條件表,如果條件表的最后一條語句的退出狀態為零,則執行盾環體內的命令
表,執行完后,再檢查條件表,如果退出狀態為零將繼續執行,如此循環往復直到條件表的
最后一條語句的退出狀態非零. 退出狀態為零就是條件為真True.
舉例說明 假如shell文件的內容如下:
Sum=0
i=0
while true #true是系統的關鍵詞 表示真
do
i=`expr $i + 1`
Sum=`expr $Sum + $i`
if [ $i = "100" ]
then
break;
fi
done
echo $i $Sum
最后這個程序顯示的是 100 5050
這個程序的運算就是將1到100加起來
下面將這個程序再改動一下
Sum=0
i=0
while [ $i != "100" ]
do
i=`expr $i + 1`
Sum=`expr $Sum + $i`
done
echo $i $Sum
改動后的程序運算結果和上面是一樣 但程序比上面的要簡練
在這個循環中還可以以until做為測試條件 它正好與while測試的條件相反,也就是當條件為假時將繼續執行循環體內的語句,否則就退出循環體,下面還用這個例子.
Sum=0
i=0
until [ $i = "100" ]
do
i=`expr $i + 1`
Sum=`expr $Sum + $i`
done
echo $i $Sum
當i不等于100時循環 就是當條件為假時循環,否則就退出,而第一個例子是當i不等于100
時循環,也就是測試條件為真時循環.
二.for 循環
命令格式:
for 變量 in 名字列表
do
命令列表
done
這里的名字列表是一個由空格分隔的字符串列表,shell在執行for循環時每次依次從名字表
中取出一個字符串賦給循環變量作為變量的值.
在寫for語句時,也可以省略in 名字列表部分,這表示用當前的位置參數來代替這時的名
字列表.
下面舉個例子
比如在你的電腦中有兩個目錄,一個是aa,一個是bb在這兩個目錄中有5個相同的文件,但其
中一個目錄中的一個或多個文件剛剛修改過,現在我忘記剛才改的是那幾個文件 了,那么我靠梢員冉弦幌掄飭礁瞿柯嫉奈募橢懶?程序如下:
for File in a1 a2 a3 a4 a5
do
diff aa/$File bb/$File
done
下面再舉一個不帶名字列表的例子
for File
do
echo $Filw
done
文件內容保存在a.sh中 并可執行
我們在執行這個shell程序時命令行如下:
a.sh a1 a2 a3 a4 a5
執行結果如下:
a1
a2
a3
a4
a5
大家從這個例子中可以看到命令行的參數被逐一讀入一次
三.循環控制語句
break 命令不執行當前循環體內break下面的語句從當前循環退出.
continue 命令是程序在本循體內忽略下面的語句,從循環頭開始執行.
一,命令組合:圓括號和花括號
shell中有兩種方法將命令組合在一起:圓括號和花括號.圓括號使shell創建一個子shell
來讀取并執行括起來的名命令.左括號和右括號不論出現在命令行中的什么位置,shell都會
認為它們具有特殊的組合意義的.只有用雙引號將它們括起來引用,才表示圓括號或花括號
的原義.例如:
echo a(b)
將出現語法上的錯誤,要想輸出a(b)字符串 只能括起來
echo "a(b)"
或echo a"("b")"
這樣才能被shell正確解釋.
利用組合命令有什么作用呢?
一,用圓括號組合命令
圓括號的組合命令可以創建子進程運行組合程序,建立子進程的功能是很有用的,因為
子shell在組合命令中的種種操作都不會影響到當前shell的各變量的值.
例如:
子進程在執行組合命令時改變了工作目錄,并在新的工作目錄下執行一系例命令,執行
完后它可以不必返回原工作目錄,因為子進程工作目錄的改變不會影響到當前工作目錄.
創建子進程后將當前的環境也同樣傳給子shell,當前shell中用export輸出到環境中的
各變量在子shell中同樣有效.
花括號也可以將命令組合在一起.左 右花括號只有作為一條命令的第一個字出現時,
shell才它們含有特殊含義.
與圓括號不同的是花括號并不創建子shell,只是由當前的shell來讀取并執行括起來的
命令.有時用戶希望使用一組命令的順序輸出作為另一組命令的輸入,此時用花括號是很方
便的.
不論是用圓括號不是花括號,退出狀態都是等于最后一條括起來的命令的退出狀態.
二,可以在當前shell中執行的命令
用戶在使用shell時一定要了解那些是可以在當前shell中執行的命令 那些不可以
可以在當前shell中執行的命令有:
break case cd continue
echo eval exec exit
export for if read
readonly return set shift
test times trap umask
until wait while
: {}