- ldd只能對共享對象，也就是動態(tài)可執(zhí)行文件使用。
ldd prints the shared objects (shared libraries) required by each program or shared object specified on the command line.
- 對/bin/sh程序使用ldd，查看其依賴的庫
- 對自己寫的程序使用ldd，可以看到，每次執(zhí)行l(wèi)dd的時(shí)候，每個(gè)依賴庫所映射的地址都不一樣，這可能和我們馬上要探索的可程序“動起來”的過程有關(guān)。和安全也有一定的關(guān)系。
- ldd man page中的解釋如下：
In the usual case, **ldd **invokes the standard dynamic linker (see ld.so(8)) with the **LD_TRACE_LOADED_OBJECTS **environment variable set to 1. This causes the dynamic linker to inspect the program's dynamic dependencies, and find (according to the rules described in ld.so(8)) and load the objects that satisfy those dependencies. For each dependency, **ldd **displays the location of the matching object and the (hexadecimal) address at which it is loaded. (The linux-vdso and ld-linux shared dependencies are special; see vdso(7) and ld.so(8).)
簡單來說，ldd實(shí)際是調(diào)用標(biāo)準(zhǔn)鏈接器來得到依賴關(guān)系。ldd會顯示以來的共享庫以及加載時(shí)在可執(zhí)行程序的虛擬地址空間中。
在ld.so的man page中，可以看到，實(shí)際上，除了我們使用ldd這種方式來調(diào)用動態(tài)鏈接器外，也可以直接用下面這樣的方式來獲取我們需要的信息：
LD_TRACE_LOADED_OBJECTS If set (to any value), causes the program to list its dynamic dependencies, as if run by ldd(1), instead of running normally.
- 動態(tài)鏈接器還會在動態(tài)可執(zhí)行程序被執(zhí)行的時(shí)候自動被調(diào)用，動態(tài)鏈接器保存在ELF文件中的.interp section中。
- 當(dāng)然了，我們主要關(guān)注的還是ELF中的動態(tài)鏈接是如何進(jìn)行的。
看看hello的結(jié)構(gòu)：
ELF Header
thorn@ubuntu:~/LinuxKernel/menu$ readelf -h hello
ELF Header:
Magic: 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - GNU
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0x8048736
Start of program headers: 52 (bytes into file)
Start of section headers: 724012 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 6
Size of section headers: 40 (bytes)
Number of section headers: 31
Section header string table index: 28
section headers
thorn@ubuntu:~/LinuxKernel/menu$ readelf -S hello
There are 31 section headers, starting at offset 0xb0c2c:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .note.ABI-tag NOTE 080480f4 0000f4 000020 00 A 0 0 4
[ 2] .note.gnu.build-i NOTE 08048114 000114 000024 00 A 0 0 4
[ 3] .rel.plt REL 08048138 000138 000070 08 AI 0 23 4
[ 4] .init PROGBITS 080481a8 0001a8 000023 00 AX 0 0 4
[ 5] .plt PROGBITS 080481d0 0001d0 0000e0 00 AX 0 0 16
[ 6] .text PROGBITS 080482b0 0002b0 07201c 00 AX 0 0 16
[ 7] __libc_freeres_fn PROGBITS 080ba2d0 0722d0 000a6d 00 AX 0 0 16
[ 8] __libc_thread_fre PROGBITS 080bad40 072d40 00009e 00 AX 0 0 16
[ 9] .fini PROGBITS 080bade0 072de0 000014 00 AX 0 0 4
[10] .rodata PROGBITS 080bae00 072e00 01a88c 00 A 0 0 32
[11] __libc_subfreeres PROGBITS 080d568c 08d68c 000028 00 A 0 0 4
[12] __libc_atexit PROGBITS 080d56b4 08d6b4 000004 00 A 0 0 4
[13] __libc_thread_sub PROGBITS 080d56b8 08d6b8 000004 00 A 0 0 4
[14] .eh_frame PROGBITS 080d56bc 08d6bc 0129d0 00 A 0 0 4
[15] .gcc_except_table PROGBITS 080e808c 0a008c 0000b1 00 A 0 0 1
[16] .tdata PROGBITS 080e9f5c 0a0f5c 000010 00 WAT 0 0 4
[17] .tbss NOBITS 080e9f6c 0a0f6c 000018 00 WAT 0 0 4
[18] .init_array INIT_ARRAY 080e9f6c 0a0f6c 000008 00 WA 0 0 4
[19] .fini_array FINI_ARRAY 080e9f74 0a0f74 000008 00 WA 0 0 4
[20] .jcr PROGBITS 080e9f7c 0a0f7c 000004 00 WA 0 0 4
[21] .data.rel.ro PROGBITS 080e9f80 0a0f80 000070 00 WA 0 0 32
[22] .got PROGBITS 080e9ff0 0a0ff0 000008 04 WA 0 0 4
[23] .got.plt PROGBITS 080ea000 0a1000 000044 04 WA 0 0 4
[24] .data PROGBITS 080ea060 0a1060 000f20 00 WA 0 0 32
[25] .bss NOBITS 080eaf80 0a1f80 000e0c 00 WA 0 0 32
[26] __libc_freeres_pt NOBITS 080ebd8c 0a1f80 000018 00 WA 0 0 4
[27] .comment PROGBITS 00000000 0a1f80 000034 01 MS 0 0 1
[28] .shstrtab STRTAB 00000000 0b0ae0 00014c 00 0 0 1
[29] .symtab SYMTAB 00000000 0a1fb4 007e50 10 30 848 4
[30] .strtab STRTAB 00000000 0a9e04 006cdc 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
當(dāng)然還有很多其他的如符號表、字符串表等等信息。
開始挖ELF的加載過程，怎么動起來的。
exec代碼如下：
int Exec(int argc, char *argv[])
{
int pid;
/* fork another process */
pid = fork();
if (pid < 0)
{
/* error occurred */
fprintf(stderr,"Fork Failed!");
exit(-1);
}
else if (pid == 0)
{
/* child process */
printf("This is Child Process!\n");
execlp("/hello","hello",NULL);
}
else
{
/* parent process */
printf("This is Parent Process!\n");
/* parent will wait for the child to complete*/
wait(NULL);
printf("Child Complete!\n");
}
}
- 可以看到，代碼中使用了exec這個(gè)系統(tǒng)調(diào)用，而且是在子進(jìn)程中使用的。exec這個(gè)系統(tǒng)調(diào)用很有意思，和fork相反，exec調(diào)用一次，從不返回，因?yàn)樗采w了調(diào)用進(jìn)程。
搭建好執(zhí)行環(huán)境：
設(shè)置了以下斷點(diǎn)：
執(zhí)行exec，和我們之前的系統(tǒng)調(diào)用一樣，停在了sys_execve
- 停在了getname處，可以看到，在查找/hello這個(gè)應(yīng)用，而在我們簡單的文件系統(tǒng)（我們的文件系統(tǒng)只有一個(gè)/根目錄）下這個(gè)hello是存在的。
-- 注：有必要研究下這個(gè)系內(nèi)核的文件系統(tǒng)是怎么實(shí)現(xiàn)的，在QEMU下用-initrd roofs.img的原理
繼續(xù)追蹤下去，可以看到，執(zhí)行了do_execv_common。停在了load_elf_binary處，這個(gè)函數(shù)很是關(guān)鍵，可以說，這個(gè)函數(shù)的實(shí)現(xiàn)部分和ELF的文件標(biāo)準(zhǔn)內(nèi)的各種section、header等打交道，要想搞明白這個(gè)，還是先把elf文件的規(guī)約讀懂。
其實(shí)一句話說完，這段代碼主要是圍繞著elf文件的格式，來準(zhǔn)備裝載一個(gè)可執(zhí)行程序所需要的各種環(huán)境。怎么說呢，應(yīng)該說是這就是和ELF相呼應(yīng)的地方。不過，若想搞明白，到底是怎樣，兩方面都要搞清楚。
- 完了到了start_thread，我理解的是，start_kernel并沒有真正的start，而是對內(nèi)核的相關(guān)寄存器做了修改。
真正start的時(shí)候，還是在調(diào)度的時(shí)候，也即是把新的進(jìn)程準(zhǔn)備好，放到調(diào)度隊(duì)列之后。
