print("hello world")

這就是在命令行下的情況：

$ python3 hello.py
hello world

但是在幕后，實際上有更多的事情在發(fā)生。我將描述一些發(fā)生的情況，并且（更重要的是）解釋一些你可以用來查看幕后情況的工具。我們將用 readelf、strace、ldd、debugfs、/proc、ltrace、dd 和 stat。我不會討論任何只針對 Python 的部分 —— 只研究一下當你運行任何動態(tài)鏈接的可執(zhí)行文件時發(fā)生的事情。

0、在執(zhí)行 execve 之前

要啟動 Python 解釋器，很多步驟都需要先行完成。那么，我們究竟在運行哪一個可執(zhí)行文件呢？它在何處呢？

1、解析 python3 hello.py

Shell 將 python3 hello.py 解析成一條命令和一組參數(shù)：python3 和 ['hello.py']。

在此過程中，可能會進行一些如全局擴展等操作。舉例來說，如果你執(zhí)行 python3 *.py ，Shell 會將其擴展到 python3 hello.py。

2、確認 python3 的完整路徑

現(xiàn)在，我們了解到需要執(zhí)行 python3。但是，這個二進制文件的完整路徑是什么呢？解決辦法是使用一個名為 PATH 的特殊環(huán)境變量。

自行驗證：在你的 Shell 中執(zhí)行 echo $PATH。對我來說，它的輸出如下：

$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

當執(zhí)行一個命令時，Shell 將會依序在 PATH 列表中的每個目錄里搜索匹配的文件。

對于 fish（我的 Shell），你可以在 這里 查看路徑解析的邏輯。它使用 stat 系統(tǒng)調(diào)用去檢驗是否存在文件。

自行驗證：執(zhí)行 strace -e stat bash，然后運行像 python3 這樣的命令。你應(yīng)該會看到如下輸出：

stat("/usr/local/sbin/python3", 0x7ffcdd871f40) = -1 ENOENT (No such file or directory)
stat("/usr/local/bin/python3", 0x7ffcdd871f40) = -1 ENOENT (No such file or directory)
stat("/usr/sbin/python3", 0x7ffcdd871f40) = -1 ENOENT (No such file or directory)
stat("/usr/bin/python3", {st_mode=S_IFREG|0755, st_size=5479736, ...}) = 0

你可以觀察到，一旦在 /usr/bin/python3 找到了二進制文件，搜索就會立即終止：它不會繼續(xù)去 /sbin 或 /bin 中查找。

對 execvp 的補充說明

如果你想要不用自己重新實現(xiàn)，而運行和 Shell 同樣的 PATH 搜索邏輯，你可以使用 libc 函數(shù) execvp（或其它一些函數(shù)名中含有 p 的 exec* 函數(shù)）。

3、stat 的背后運作機制

你可能在思考，Julia，stat 到底做了什么？當你的操作系統(tǒng)要打開一個文件時，主要分為兩個步驟：

1. 它將 文件名 映射到一個包含該文件元數(shù)據(jù)的 inode
2. 它利用這個 inode 來獲取文件的實際內(nèi)容

stat 系統(tǒng)調(diào)用只是返回文件的 inode 內(nèi)容 —— 它并不讀取任何的文件內(nèi)容。好處在于這樣做速度非常快。接下來讓我們一起來快速了解一下 inode。（在 Dmitry Mazin 的這篇精彩文章 《磁盤就是一堆比特》中有更多的詳細內(nèi)容）

$ stat /usr/bin/python3
  File: /usr/bin/python3 -> python3.9
  Size: 9           Blocks: 0          IO Block: 4096   symbolic link
Device: fe01h/65025d    Inode: 6206        Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-08-03 14:17:28.890364214 +0000
Modify: 2021-04-05 12:00:48.000000000 +0000
Change: 2021-06-22 04:22:50.936969560 +0000
 Birth: 2021-06-22 04:22:50.924969237 +0000

自行驗證：我們來實際查看一下硬盤上 inode 的確切位置。

首先，我們需要找出硬盤的設(shè)備名稱：

$ df
...
tmpfs             100016      604     99412   1% /run
/dev/vda1       25630792 14488736  10062712  60% /
...

看起來它是 /dev/vda1。接著，讓我們尋找 /usr/bin/python3 的 inode 在我們硬盤上的確切位置（在 debugfs 提示符下輸入 imap 命令）：

$ sudo debugfs /dev/vda1
debugfs 1.46.2 (28-Feb-2021)
debugfs:  imap /usr/bin/python3
Inode 6206 is part of block group 0
    located at block 658, offset 0x0d00

我不清楚 debugfs 是如何確定文件名對應(yīng)的 inode 的位置，但我們暫時不需要深入研究這個。

現(xiàn)在，我們需要計算硬盤中 “塊 658，偏移量 0x0d00” 處是多少個字節(jié)，這個大的字節(jié)數(shù)組就是你的硬盤。每個塊有 4096 個字節(jié)，所以我們需要到 4096 * 658 + 0x0d00 字節(jié)。使用計算器可以得到，這個值是 2698496。

$ sudo dd if=/dev/vda1 bs=1 skip=2698496 count=256 2>/dev/null | hexdump -C
00000000  ff a1 00 00 09 00 00 00  f8 b6 cb 64 9a 65 d1 60  |...........d.e.`|
00000010  f0 fb 6a 60 00 00 00 00  00 00 01 00 00 00 00 00  |..j`............|
00000020  00 00 00 00 01 00 00 00  70 79 74 68 6f 6e 33 2e  |........python3.|
00000030  39 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |9...............|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000060  00 00 00 00 12 4a 95 8c  00 00 00 00 00 00 00 00  |.....J..........|
00000070  00 00 00 00 00 00 00 00  00 00 00 00 2d cb 00 00  |............-...|
00000080  20 00 bd e7 60 15 64 df  00 00 00 00 d8 84 47 d4  | ...`.d.......G.|
00000090  9a 65 d1 60 54 a4 87 dc  00 00 00 00 00 00 00 00  |.e.`T...........|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

好極了！我們找到了 inode！你可以在里面看到 python3，這是一個很好的跡象。我們并不打算深入了解所有這些，但是 Linux 內(nèi)核的 ext4 inode 結(jié)構(gòu) 指出，前 16 位是 “模式”，即權(quán)限。所以現(xiàn)在我們將看一下 ffa1 如何對應(yīng)到文件權(quán)限。

• ffa1 對應(yīng)的數(shù)字是 0xa1ff，或者 41471（因為 x86 是小端表示）
• 41471 用八進制表示就是 0120777
• 這有些奇怪 - 那個文件的權(quán)限肯定可以是 777，但前三位是什么呢？我以前沒見過這些！你可以在 inode 手冊頁 中找到 012 的含義（向下滾動到“文件類型和模式”）。這里有一個小的表格說 012 表示 “符號鏈接”。

我們查看一下這個文件，確實是一個權(quán)限為 777 的符號鏈接：

$ ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 9 Apr  5  2021 /usr/bin/python3 -> python3.9

它確實是！耶，我們正確地解碼了它。

4、準備復刻

我們尚未準備好啟動 python3。首先，Shell 需要創(chuàng)建一個新的子進程來進行運行。在 Unix 上，新的進程啟動的方式有些特殊 - 首先進程克隆自己，然后運行 execve，這會將克隆的進程替換為新的進程。

自行驗證： 運行 strace -e clone bash，然后運行 python3。你應(yīng)該會看到類似下面的輸出：

clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f03788f1a10) = 3708100

3708100 是新進程的 PID，這是 Shell 進程的子進程。

這里有些工具可以查看進程的相關(guān)信息：

• pstree 會展示你的系統(tǒng)中所有進程的樹狀圖
• cat /proc/PID/stat 會顯示一些關(guān)于該進程的信息。你可以在 man proc 中找到這個文件的內(nèi)容說明。例如，第四個字段是父進程的PID。

新進程的繼承

新的進程（即將變?yōu)?nbsp;python3 的）從 Shell 中繼承了很多內(nèi)容。例如，它繼承了：

1. 環(huán)境變量：你可以通過 cat /proc/PID/environ | tr '\0' '\n' 查看
2. 標準輸出和標準錯誤的文件描述符：通過 ls -l /proc/PID/fd 查看
3. 工作目錄（也就是當前目錄）
4. 命名空間和控制組（如果它在一個容器內(nèi)）
5. 運行它的用戶以及群組
6. 還有可能是我此刻未能列舉出來的更多東西

5、Shell 調(diào)用 execve

現(xiàn)在我們準備好啟動 Python 解釋器了！

自行驗證：運行 strace -f -e execve bash，接著運行 python3。其中的 -f 參數(shù)非常重要，因為我們想要跟蹤任何可能產(chǎn)生的子進程。你應(yīng)該可以看到如下的輸出：

[pid 3708381] execve("/usr/bin/python3", ["python3"], 0x560397748300 /* 21 vars */) = 0

第一個參數(shù)是這個二進制文件，而第二個參數(shù)是命令行參數(shù)列表。這些命令行參數(shù)被放置在程序內(nèi)存的特定位置，以便在運行時可以訪問。

那么，execve 內(nèi)部到底發(fā)生了什么呢？

6、獲取該二進制文件的內(nèi)容

我們首先需要打開 python3 的二進制文件并讀取其內(nèi)容。直到目前為止，我們只使用了 stat 系統(tǒng)調(diào)用來獲取其元數(shù)據(jù)，但現(xiàn)在我們需要獲取它的內(nèi)容。

讓我們再次查看 stat 的輸出：

$ stat /usr/bin/python3
  File: /usr/bin/python3 -> python3.9
  Size: 9           Blocks: 0          IO Block: 4096   symbolic link
Device: fe01h/65025d    Inode: 6206        Links: 1
...

該文件在磁盤上占用 0 個塊的空間。這是因為符號鏈接（python3.9）的內(nèi)容實際上是存儲在 inode 自身中：在下面顯示你可以看到（來自上述 inode 的二進制內(nèi)容，以 hexdump 格式分為兩行輸出）。

00000020  00 00 00 00 01 00 00 00  70 79 74 68 6f 6e 33 2e  |........python3.|
00000030  39 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |9...............|

因此，我們將需要打開 /usr/bin/python3.9 。所有這些操作都在內(nèi)核內(nèi)部進行，所以你并不會看到其他的系統(tǒng)調(diào)用。

每個文件都由硬盤上的一系列的 塊 構(gòu)成。我知道我系統(tǒng)中的每個塊是 4096 字節(jié)，所以一個文件的最小大小是 4096 字節(jié) —— 甚至如果文件只有 5 字節(jié)，它在磁盤上仍然占用 4KB。

自行驗證：我們可以通過 debugfs 找到塊號，如下所示：（再次說明，我從 Dmitry Mazin 的《磁盤就是一堆比特》文章中得知這些步驟）。

$ debugfs /dev/vda1
debugfs:  blocks /usr/bin/python3.9
145408 145409 145410 145411 145412 145413 145414 145415 145416 145417 145418 145419 145420 145421 145422 145423 145424 145425 145426 145427 145428 145429 145430 145431 145432 145433 145434 145435 145436 145437

接下來，我們可以使用 dd 來讀取文件的第一個塊。我們將塊大小設(shè)定為 4096 字節(jié)，跳過 145408 個塊，然后讀取 1 個塊。

$ dd if=/dev/vda1 bs=4096 skip=145408 count=1 2>/dev/null | hexdump -C | head
00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 3e 00 01 00 00 00  c0 a5 5e 00 00 00 00 00  |..>.......^.....|
00000020  40 00 00 00 00 00 00 00  b8 95 53 00 00 00 00 00  |@.........S.....|
00000030  00 00 00 00 40 00 38 00  0b 00 40 00 1e 00 1d 00  |....@.8...@.....|
00000040  06 00 00 00 04 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000050  40 00 40 00 00 00 00 00  40 00 40 00 00 00 00 00  |@.@.....@.@.....|
00000060  68 02 00 00 00 00 00 00  68 02 00 00 00 00 00 00  |h.......h.......|
00000070  08 00 00 00 00 00 00 00  03 00 00 00 04 00 00 00  |................|
00000080  a8 02 00 00 00 00 00 00  a8 02 40 00 00 00 00 00  |..........@.....|
00000090  a8 02 40 00 00 00 00 00  1c 00 00 00 00 00 00 00  |..@.............|

你會發(fā)現(xiàn)，這樣我們得到的輸出結(jié)果與直接使用 cat 讀取文件所獲得的結(jié)果完全一致。

$ cat /usr/bin/python3.9 | hexdump -C | head
00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 3e 00 01 00 00 00  c0 a5 5e 00 00 00 00 00  |..>.......^.....|
00000020  40 00 00 00 00 00 00 00  b8 95 53 00 00 00 00 00  |@.........S.....|
00000030  00 00 00 00 40 00 38 00  0b 00 40 00 1e 00 1d 00  |....@.8...@.....|
00000040  06 00 00 00 04 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000050  40 00 40 00 00 00 00 00  40 00 40 00 00 00 00 00  |@.@.....@.@.....|
00000060  68 02 00 00 00 00 00 00  68 02 00 00 00 00 00 00  |h.......h.......|
00000070  08 00 00 00 00 00 00 00  03 00 00 00 04 00 00 00  |................|
00000080  a8 02 00 00 00 00 00 00  a8 02 40 00 00 00 00 00  |..........@.....|
00000090  a8 02 40 00 00 00 00 00  1c 00 00 00 00 00 00 00  |..@.............|

關(guān)于魔術(shù)數(shù)字的額外說明

這個文件以 ELF 開頭，這是一個被稱為“魔術(shù)數(shù)字magic number”的標識符，它是一種字節(jié)序列，告訴我們這是一個 ELF 文件。在 Linux 上，ELF 是二進制文件的格式。

不同的文件格式有不同的魔術(shù)數(shù)字。例如，gzip 的魔數(shù)是 1f8b。文件開頭的魔術(shù)數(shù)字就是 file blah.gz 如何識別出它是一個 gzip 文件的方式。

我認為 file 命令使用了各種啟發(fā)式方法來確定文件的類型，而其中，魔術(shù)數(shù)字是一個重要的特征。

7、尋找解釋器

我們來解析這個 ELF 文件，看看里面都有什么內(nèi)容。

自行驗證：運行 readelf -a /usr/bin/python3.9。我得到的結(jié)果是這樣的（但是我刪減了大量的內(nèi)容）：

$ readelf -a /usr/bin/python3.9
ELF Header:
    Class:                             ELF64
    Machine:                           Advanced Micro Devices X86-64
...
->  Entry point address:               0x5ea5c0
...
Program Headers:
  Type           Offset             VirtAddr           PhysAddr
  INTERP         0x00000000000002a8 0x00000000004002a8 0x00000000004002a8
                 0x000000000000001c 0x000000000000001c  R      0x1
->      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
        ...
->        1238: 00000000005ea5c0    43 FUNC    GLOBAL DEFAULT   13 _start

從這段內(nèi)容中，我理解到：

1. 請求內(nèi)核運行 /lib64/ld-linux-x86-64.so.2 來啟動這個程序。這就是所謂的動態(tài)鏈接器，我們將在隨后的部分對其進行討論。
2. 該程序制定了一個入口點（位于 0x5ea5c0），那里是這個程序代碼開始的地方。

接下來，讓我們一起來聊聊動態(tài)鏈接器。

8、動態(tài)鏈接

好的！我們已從磁盤讀取了字節(jié)數(shù)據(jù)，并啟動了這個“解釋器”。那么，接下來會發(fā)生什么呢？如果你執(zhí)行 strace -o out.strace python3，你會在 execve 系統(tǒng)調(diào)用之后觀察到一系列的信息：

execve("/usr/bin/python3", ["python3"], 0x560af13472f0 /* 21 vars */) = 0
brk(NULL)                       = 0xfcc000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=32091, ...}) = 0
mmap(NULL, 32091, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f718a1e3000
close(3)                        = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 l\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=149520, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f718a1e1000
...
close(3)                        = 0
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3

這些內(nèi)容初看可能讓人望而生畏，但我希望你能重點關(guān)注這一部分：openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0" ...。這里正在打開一個被稱為 pthread 的 C 語言線程庫，運行 Python 解釋器時需要這個庫。

自行驗證：如果你想知道一個二進制文件在運行時需要加載哪些庫，你可以使用 ldd 命令。下面展示的是我運行后的效果：

$ ldd /usr/bin/python3.9
    linux-vdso.so.1 (0x00007ffc2aad7000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2fd6554000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2fd654e000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f2fd6549000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2fd6405000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f2fd63d6000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2fd63b9000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2fd61e3000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2fd6580000)

你可以看到，第一個列出的庫就是 /lib/x86_64-linux-gnu/libpthread.so.0，這就是它被第一個加載的原因。

關(guān)于 LD_LIBRARY_PATH

說實話，我關(guān)于動態(tài)鏈接的理解還有些模糊，以下是我所了解的一些內(nèi)容：

• 動態(tài)鏈接發(fā)生在用戶空間，我的系統(tǒng)上的動態(tài)鏈接器位于 /lib64/ld-linux-x86-64.so.2. 如果你缺少動態(tài)鏈接器，可能會遇到一些奇怪的問題，比如這種 奇怪的“文件未找到”錯誤
• 動態(tài)鏈接器使用 LD_LIBRARY_PATH 環(huán)境變量來查找?guī)?/li>
• 動態(tài)鏈接器也會使用 LD_PRELOAD 環(huán)境變量來覆蓋你想要的任何動態(tài)鏈接函數(shù)（你可以使用它來進行 有趣的魔改，或者使用像 jemalloc 這樣的替代品來替換默認內(nèi)存分配器）
• strace 的輸出中有一些 mprotect，因為安全原因?qū)齑a標記為只讀
• 在 Mac 上，不是使用 LD_LIBRARY_PATH（Linux），而是 DYLD_LIBRARY_PATH

你可能會有疑問，如果動態(tài)鏈接發(fā)生在用戶空間，我們?yōu)槭裁礇]有看到大量的 stat 系統(tǒng)調(diào)用在 LD_LIBRARY_PATH 中搜索這些庫，就像 Bash 在 PATH 中搜索那樣？

這是因為 ld 在 /etc/ld.so.cache 中有一個緩存，因此所有之前已經(jīng)找到的庫都會被記錄在這里。你可以在 strace 的輸出中看到它正在打開緩存 - openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3。

在 完整的 strace 輸出 中，我仍然對動態(tài)鏈接之后出現(xiàn)的一些系統(tǒng)調(diào)用感到困惑（什么是 prlimit64？本地環(huán)境的內(nèi)容是如何介入的？gconv-modules.cache 是什么？rt_sigaction 做了什么？arch_prctl 是什么？以及 set_tid_address 和 set_robust_list 是什么？）。盡管如此，我覺得已經(jīng)有了一個不錯的開頭。

旁注：ldd 實際上是一個簡單的 Shell 腳本！

在 Mastodon 上，有人 指出，ldd 實際上是一個 Shell 腳本，它設(shè)置了 LD_TRACE_LOADED_OBJECTS=1 環(huán)境變量，然后啟動程序。因此，你也可以通過以下方式實現(xiàn)相同的功能：

$ LD_TRACE_LOADED_OBJECTS=1 python3
    linux-vdso.so.1 (0x00007ffe13b0a000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f01a5a47000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f01a5a41000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f2fd6549000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2fd6405000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f2fd63d6000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2fd63b9000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2fd61e3000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2fd6580000)

事實上，ld 也是一個可以直接運行的二進制文件，所以你也可以通過 /lib64/ld-linux-x86-64.so.2 --list /usr/bin/python3.9 來達到相同的效果。

關(guān)于 init 和 fini

讓我們來談?wù)勥@行 strace 輸出中的內(nèi)容：

set_tid_address(0x7f58880dca10) = 3709103

這似乎與線程有關(guān)，我認為這可能是因為 pthread 庫（以及所有其他動態(tài)加載的庫）在加載時得以運行初始化代碼。在庫加載時運行的代碼位于 init 區(qū)域（或者也可能是 .ctors 區(qū)域）。

自行驗證：讓我們使用 readelf 來看看這個：

$ readelf -a /lib/x86_64-linux-gnu/libpthread.so.0
...
  [10] .rela.plt         RELA             00000000000051f0  000051f0
       00000000000007f8  0000000000000018  AI       4    26     8
  [11] .init             PROGBITS         0000000000006000  00006000
       000000000000000e  0000000000000000  AX       0     0     4
  [12] .plt              PROGBITS         0000000000006010  00006010
       0000000000000560  0000000000000010  AX       0     0     16
...

這個庫沒有 .ctors 區(qū)域，只有一個 .init。但是，.init 區(qū)域都有些什么內(nèi)容呢？我們可以使用 objdump 來反匯編這段代碼：

$ objdump -d /lib/x86_64-linux-gnu/libpthread.so.0
Disassembly of section .init:

0000000000006000 <_init>:
    6000:       48 83 ec 08             sub    $0x8,%rsp
    6004:       e8 57 08 00 00          callq  6860 <__pthread_initialize_minimal>
    6009:       48 83 c4 08             add    $0x8,%rsp
    600d:       c3

所以它在調(diào)用 __pthread_initialize_minimal。我在 glibc 中找到了 這個函數(shù)的代碼，盡管我不得不找到一個較早版本的 glibc，因為在更近的版本中，libpthread 不再是一個獨立的庫。

我不確定這個 set_tid_address 系統(tǒng)調(diào)用是否實際上來自 __pthread_initialize_minimal，但至少我們知道了庫可以通過 .init 區(qū)域在啟動時運行代碼。

這里有一份關(guān)于 .init 區(qū)域的 elf 手冊的筆記：

$ man elf

.init 這個區(qū)域保存著對進程初始化代碼有貢獻的可執(zhí)行指令。當程序開始運行時，系統(tǒng)會安排在調(diào)用主程序入口點之前執(zhí)行該區(qū)域中的代碼。

在 ELF 文件中也有一個在結(jié)束時運行的 .fini 區(qū)域，以及其他可以存在的區(qū)域 .ctors / .dtors（構(gòu)造器和析構(gòu)器）。

好的，關(guān)于動態(tài)鏈接就說這么多。

9、轉(zhuǎn)到 _start

在動態(tài)鏈接完成后，我們進入到 Python 解釋器中的 _start。然后，它將執(zhí)行所有正常的 Python 解析器會做的事情。

我不打算深入討論這個，因為我在這里關(guān)心的是關(guān)于如何在 Linux 上運行二進制文件的一般性知識，而不是特別針對 Python 解釋器。

10、寫入字符串

不過，我們?nèi)匀恍枰蛴〕?“hello world”。在底層，Python 的 print 函數(shù)調(diào)用了 libc 中的某個函數(shù)。但是，它調(diào)用了哪一個呢？讓我們來找出答案！

自行驗證：運行 ltrace -o out python3 hello.py：

$ ltrace -o out python3 hello.py
$ grep hello out
write(1, "hello world\n", 12) = 12

看起來它確實在調(diào)用 write 函數(shù)。

我必須承認，我對 ltrace 總是有一些疑慮 —— 與我深信不疑的 strace 不同，我總是不完全確定 ltrace 是否準確地報告了庫調(diào)用。但在這個情況下，它似乎有效。并且，如果我們查閱 cpython 的源代碼，它似乎在一些地方確實調(diào)用了 write() 函數(shù)，所以我傾向于相信這個結(jié)果。

什么是 libc？

我們剛剛提到，Python 調(diào)用了 libc 中的 write 函數(shù)。那么，libc 是什么呢？它是 C 的標準庫，負責許多基本操作，例如：

• 用 malloc 分配內(nèi)存
• 文件 I/O（打開/關(guān)閉文件）
• 執(zhí)行程序（像我們之前提到的 execvp）
• 使用 getaddrinfo 查找 DNS 記錄
• 使用 pthread 管理線程

在 Linux 上，程序不一定需要使用 libc（例如 Go 就廣為人知地未使用它，而是直接調(diào)用了 Linux 系統(tǒng)調(diào)用），但是我常用的大多數(shù)其他編程語言（如 node、Python、Ruby、Rust）都使用了 libc。我不確定 Java 是否也使用了。

你能通過在你的二進制文件上執(zhí)行 ldd 命令，檢查你是否正在使用 libc：如果你看到了 libc.so.6 這樣的信息，那么你就在使用 libc。

為什么 libc 重要？

你也許在思考 —— 為何重要的是 Python 調(diào)用 libc 的 write 函數(shù)，然后 libc 再調(diào)用 write 系統(tǒng)調(diào)用？為何我要著重提及 libc 是調(diào)用過程的一環(huán)？

我認為，在這個案例中，這并不真的很重要（根據(jù)我所知，libc 的 write 函數(shù)與 write 系統(tǒng)調(diào)用的映射相當直接）。

然而，存在不同的 libc 實現(xiàn)，有時它們的行為會有所不同。兩個主要的實現(xiàn)是 glibc（GNU libc）和 musl libc。

例如，直到最近，musl 的 getaddrinfo，這是一篇關(guān)于這個問題引發(fā)的錯誤的博客文章。

關(guān)于 stdout 和終端的小插曲

在我們的程序中，stdout（1 文件描述符）是一個終端。你可以在終端上做一些有趣的事情！例如：

1. 在終端中運行 ls -l /proc/self/fd/1。我得到了 /dev/pts/2 的結(jié)果。
2. 在另一個終端窗口中，運行 echo hello > /dev/pts/2。
3. 返回到原始終端窗口。你應(yīng)會看到 hello 被打印出來了！

暫時就到這兒吧!

希望通過上文，你對 hello world 是如何打印出來的有了更深的了解！我暫時不再添加更多的細節(jié)，因為這篇文章已經(jīng)足夠長了，但顯然還有更多的細節(jié)可以探討，如果大家能提供更多的細節(jié)，我可能會添加更多的內(nèi)容。如果你有關(guān)于我在這里沒提到的程序內(nèi)部調(diào)用過程的任何工具推薦，我會特別高興。

我很期待看到一份 Mac 版的解析

我對 Mac OS 的一個懊惱是，我不知道如何在這個級別上解讀我的系統(tǒng)——當我打印 “hello world”，我無法像在 Linux 上那樣，窺視背后的運作機制。我很希望看到一個深度的解析。

我所知道的一些在 Mac 下的對應(yīng)工具：

• ldd -> otool -L
• readelf -> otool
• 有人說你可以在 Mac 上使用 dtruss 或 dtrace 來代替 strace，但我尚未有足夠的勇氣關(guān)閉系統(tǒng)完整性保護來讓它工作。
• strace -> sc_usage 似乎能夠收集關(guān)于系統(tǒng)調(diào)用使用情況的統(tǒng)計信息，fs_usage 則可以收集文件使用情況的信息。

延伸閱讀

一些附加的鏈接：

• 快速教程：如何在 Linux 上創(chuàng)建超小型 ELF 可執(zhí)行文件
• 在 FreeBSD 上探索 “hello world”
• [微觀視角下的 Windows 中 “Hello World”][23A]
• 來自 LWN 的文章：如何運行程序 （以及第二部分）詳盡介紹了 execve 的內(nèi)部機制
• Lexi Mattick 的文章，賦予 CPU “你” 的存在
• 從零開始在 6502 上實現(xiàn) “Hello, World” （來自 Ben Eater 的視頻）