Linux 下“Hello World”的幕后發生了什么
print("hello world")這就是在命令行下的情況：
$ python3 hello.py
hello world但是在幕后，實際上有更多的事情在發生。我將描述一些發生的情況，并且（更重要的是）解釋一些你可以用來查看幕后情況的工具。我們將用 readelf、strace、ldd、debugfs、/proc、ltrace、dd 和 stat。我不會討論任何只針對 Python 的部分 —— 只研究一下當你運行任何動態鏈接的可執行文件時發生的事情。
0、在執行 execve 之前
要啟動 Python 解釋器，很多步驟都需要先行完成。那么，我們究竟在運行哪一個可執行文件呢？它在何處呢？
1、解析 python3 hello.py
Shell 將 python3 hello.py 解析成一條命令和一組參數：python3 和 ['hello.py']。
在此過程中，可能會進行一些如全局擴展等操作。舉例來說，如果你執行 python3 *.py ，Shell 會將其擴展到 python3 hello.py。
2、確認 python3 的完整路徑
現在，我們了解到需要執行 python3。但是，這個二進制文件的完整路徑是什么呢？解決辦法是使用一個名為 PATH 的特殊環境變量。
自行驗證：在你的 Shell 中執行 echo $PATH。對我來說，它的輸出如下：
$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin當執行一個命令時，Shell 將會依序在 PATH 列表中的每個目錄里搜索匹配的文件。
對于 fish（我的 Shell），你可以在 這里 查看路徑解析的邏輯。它使用 stat 系統調用去檢驗是否存在文件。
自行驗證：執行 strace -e stat bash，然后運行像 python3 這樣的命令。你應該會看到如下輸出：
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 找到了二進制文件，搜索就會立即終止：它不會繼續去 /sbin 或 /bin 中查找。
對 execvp 的補充說明
如果你想要不用自己重新實現，而運行和 Shell 同樣的 PATH 搜索邏輯，你可以使用 libc 函數 execvp（或其它一些函數名中含有 p 的 exec* 函數）。
3、stat 的背后運作機制
你可能在思考，Julia，stat 到底做了什么？當你的操作系統要打開一個文件時，主要分為兩個步驟：
- 它將 文件名 映射到一個包含該文件元數據的 inode
- 它利用這個 inode 來獲取文件的實際內容
stat 系統調用只是返回文件的 inode 內容 —— 它并不讀取任何的文件內容。好處在于這樣做速度非常快。接下來讓我們一起來快速了解一下 inode。（在 Dmitry Mazin 的這篇精彩文章 《磁盤就是一堆比特》中有更多的詳細內容）
$ 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 的確切位置。
首先，我們需要找出硬盤的設備名稱：
$ 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 是如何確定文件名對應的 inode 的位置，但我們暫時不需要深入研究這個。
現在，我們需要計算硬盤中 “塊 658，偏移量 0x0d00” 處是多少個字節，這個大的字節數組就是你的硬盤。每個塊有 4096 個字節，所以我們需要到 4096 * 658 + 0x0d00 字節。使用計算器可以得到，這個值是 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 內核的 ext4 inode 結構 指出，前 16 位是 “模式”，即權限。所以現在我們將看一下 ffa1 如何對應到文件權限。
ffa1對應的數字是0xa1ff，或者 41471（因為 x86 是小端表示）- 41471 用八進制表示就是
0120777 - 這有些奇怪 - 那個文件的權限肯定可以是
777，但前三位是什么呢？我以前沒見過這些！你可以在 inode 手冊頁 中找到012的含義（向下滾動到“文件類型和模式”）。這里有一個小的表格說012表示 “符號鏈接”。
我們查看一下這個文件，確實是一個權限為 777 的符號鏈接：
$ ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 9 Apr 5 2021 /usr/bin/python3 -> python3.9它確實是！耶，我們正確地解碼了它。
4、準備復刻
我們尚未準備好啟動 python3。首先，Shell 需要創建一個新的子進程來進行運行。在 Unix 上，新的進程啟動的方式有些特殊 - 首先進程克隆自己，然后運行 execve，這會將克隆的進程替換為新的進程。
自行驗證： 運行 strace -e clone bash，然后運行 python3。你應該會看到類似下面的輸出：
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f03788f1a10) = 37081003708100 是新進程的 PID，這是 Shell 進程的子進程。
這里有些工具可以查看進程的相關信息：
pstree會展示你的系統中所有進程的樹狀圖cat /proc/PID/stat會顯示一些關于該進程的信息。你可以在man proc中找到這個文件的內容說明。例如，第四個字段是父進程的PID。
新進程的繼承
新的進程（即將變為 python3 的）從 Shell 中繼承了很多內容。例如，它繼承了：
- 環境變量：你可以通過
cat /proc/PID/environ | tr '\0' '\n'查看 - 標準輸出和標準錯誤的文件描述符：通過
ls -l /proc/PID/fd查看 - 工作目錄（也就是當前目錄）
- 命名空間和控制組（如果它在一個容器內）
- 運行它的用戶以及群組
- 還有可能是我此刻未能列舉出來的更多東西
5、Shell 調用 execve
現在我們準備好啟動 Python 解釋器了！
自行驗證：運行 strace -f -e execve bash，接著運行 python3。其中的 -f 參數非常重要，因為我們想要跟蹤任何可能產生的子進程。你應該可以看到如下的輸出：
[pid 3708381] execve("/usr/bin/python3", ["python3"], 0x560397748300 /* 21 vars */) = 0第一個參數是這個二進制文件，而第二個參數是命令行參數列表。這些命令行參數被放置在程序內存的特定位置，以便在運行時可以訪問。
那么，execve 內部到底發生了什么呢？
6、獲取該二進制文件的內容
我們首先需要打開 python3 的二進制文件并讀取其內容。直到目前為止，我們只使用了 stat 系統調用來獲取其元數據，但現在我們需要獲取它的內容。
讓我們再次查看 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）的內容實際上是存儲在 inode 自身中：在下面顯示你可以看到（來自上述 inode 的二進制內容，以 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 。所有這些操作都在內核內部進行，所以你并不會看到其他的系統調用。
每個文件都由硬盤上的一系列的 塊 構成。我知道我系統中的每個塊是 4096 字節，所以一個文件的最小大小是 4096 字節 —— 甚至如果文件只有 5 字節，它在磁盤上仍然占用 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 來讀取文件的第一個塊。我們將塊大小設定為 4096 字節，跳過 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 |..@.............|你會發現，這樣我們得到的輸出結果與直接使用 cat 讀取文件所獲得的結果完全一致。
$ 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 |..@.............|關于魔術數字的額外說明
這個文件以 ELF 開頭，這是一個被稱為“魔術數字magic number”的標識符，它是一種字節序列，告訴我們這是一個 ELF 文件。在 Linux 上，ELF 是二進制文件的格式。
不同的文件格式有不同的魔術數字。例如，gzip 的魔數是 1f8b。文件開頭的魔術數字就是 file blah.gz 如何識別出它是一個 gzip 文件的方式。
我認為 file 命令使用了各種啟發式方法來確定文件的類型，而其中，魔術數字是一個重要的特征。
7、尋找解釋器
我們來解析這個 ELF 文件，看看里面都有什么內容。
自行驗證：運行 readelf -a /usr/bin/python3.9。我得到的結果是這樣的（但是我刪減了大量的內容）：
$ 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從這段內容中，我理解到：
- 請求內核運行
/lib64/ld-linux-x86-64.so.2來啟動這個程序。這就是所謂的動態鏈接器，我們將在隨后的部分對其進行討論。 - 該程序制定了一個入口點（位于
0x5ea5c0），那里是這個程序代碼開始的地方。
接下來，讓我們一起來聊聊動態鏈接器。
8、動態鏈接
好的！我們已從磁盤讀取了字節數據，并啟動了這個“解釋器”。那么，接下來會發生什么呢？如果你執行 strace -o out.strace python3，你會在 execve 系統調用之后觀察到一系列的信息：
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這些內容初看可能讓人望而生畏，但我希望你能重點關注這一部分：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，這就是它被第一個加載的原因。
關于 LD_LIBRARY_PATH
說實話，我關于動態鏈接的理解還有些模糊，以下是我所了解的一些內容：
- 動態鏈接發生在用戶空間，我的系統上的動態鏈接器位于
/lib64/ld-linux-x86-64.so.2. 如果你缺少動態鏈接器，可能會遇到一些奇怪的問題，比如這種 奇怪的“文件未找到”錯誤 - 動態鏈接器使用
LD_LIBRARY_PATH環境變量來查找庫 - 動態鏈接器也會使用
LD_PRELOAD環境變量來覆蓋你想要的任何動態鏈接函數（你可以使用它來進行 有趣的魔改，或者使用像 jemalloc 這樣的替代品來替換默認內存分配器） strace的輸出中有一些mprotect，因為安全原因將庫代碼標記為只讀- 在 Mac 上，不是使用
LD_LIBRARY_PATH（Linux），而是DYLD_LIBRARY_PATH
你可能會有疑問，如果動態鏈接發生在用戶空間，我們為什么沒有看到大量的 stat 系統調用在 LD_LIBRARY_PATH 中搜索這些庫，就像 Bash 在 PATH 中搜索那樣？
這是因為 ld 在 /etc/ld.so.cache 中有一個緩存，因此所有之前已經找到的庫都會被記錄在這里。你可以在 strace 的輸出中看到它正在打開緩存 - openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3。
在 完整的 strace 輸出 中，我仍然對動態鏈接之后出現的一些系統調用感到困惑（什么是 prlimit64？本地環境的內容是如何介入的？gconv-modules.cache 是什么？rt_sigaction 做了什么？arch_prctl 是什么？以及 set_tid_address 和 set_robust_list 是什么？）。盡管如此，我覺得已經有了一個不錯的開頭。
旁注：ldd 實際上是一個簡單的 Shell 腳本！
在 Mastodon 上，有人 指出，ldd 實際上是一個 Shell 腳本，它設置了 LD_TRACE_LOADED_OBJECTS=1 環境變量，然后啟動程序。因此，你也可以通過以下方式實現相同的功能：
$ 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 來達到相同的效果。
關于 init 和 fini
讓我們來談談這行 strace 輸出中的內容：
set_tid_address(0x7f58880dca10) = 3709103這似乎與線程有關，我認為這可能是因為 pthread 庫（以及所有其他動態加載的庫）在加載時得以運行初始化代碼。在庫加載時運行的代碼位于 init 區域（或者也可能是 .ctors 區域）。
自行驗證：讓我們使用 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 區域，只有一個 .init。但是，.init 區域都有些什么內容呢？我們可以使用 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所以它在調用 __pthread_initialize_minimal。我在 glibc 中找到了 這個函數的代碼，盡管我不得不找到一個較早版本的 glibc，因為在更近的版本中，libpthread 不再是一個獨立的庫。
我不確定這個 set_tid_address 系統調用是否實際上來自 __pthread_initialize_minimal，但至少我們知道了庫可以通過 .init 區域在啟動時運行代碼。
這里有一份關于 .init 區域的 elf 手冊的筆記：
$ man elf.init 這個區域保存著對進程初始化代碼有貢獻的可執行指令。當程序開始運行時，系統會安排在調用主程序入口點之前執行該區域中的代碼。
在 ELF 文件中也有一個在結束時運行的 .fini 區域，以及其他可以存在的區域 .ctors / .dtors（構造器和析構器）。
好的，關于動態鏈接就說這么多。
9、轉到 _start
在動態鏈接完成后，我們進入到 Python 解釋器中的 _start。然后，它將執行所有正常的 Python 解析器會做的事情。
我不打算深入討論這個，因為我在這里關心的是關于如何在 Linux 上運行二進制文件的一般性知識，而不是特別針對 Python 解釋器。
10、寫入字符串
不過，我們仍然需要打印出 “hello world”。在底層，Python 的 print 函數調用了 libc 中的某個函數。但是，它調用了哪一個呢？讓我們來找出答案！
自行驗證：運行 ltrace -o out python3 hello.py：
$ ltrace -o out python3 hello.py
$ grep hello out
write(1, "hello world\n", 12) = 12看起來它確實在調用 write 函數。
我必須承認，我對 ltrace 總是有一些疑慮 —— 與我深信不疑的 strace 不同，我總是不完全確定 ltrace 是否準確地報告了庫調用。但在這個情況下，它似乎有效。并且，如果我們查閱 cpython 的源代碼，它似乎在一些地方確實調用了 write() 函數，所以我傾向于相信這個結果。
什么是 libc？
我們剛剛提到，Python 調用了 libc 中的 write 函數。那么，libc 是什么呢？它是 C 的標準庫，負責許多基本操作，例如：
- 用
malloc分配內存 - 文件 I/O（打開/關閉文件）
- 執行程序（像我們之前提到的
execvp） - 使用
getaddrinfo查找 DNS 記錄 - 使用
pthread管理線程
在 Linux 上，程序不一定需要使用 libc（例如 Go 就廣為人知地未使用它，而是直接調用了 Linux 系統調用），但是我常用的大多數其他編程語言（如 node、Python、Ruby、Rust）都使用了 libc。我不確定 Java 是否也使用了。
你能通過在你的二進制文件上執行 ldd 命令，檢查你是否正在使用 libc：如果你看到了 libc.so.6 這樣的信息，那么你就在使用 libc。
為什么 libc 重要？
你也許在思考 —— 為何重要的是 Python 調用 libc 的 write 函數，然后 libc 再調用 write 系統調用？為何我要著重提及 libc 是調用過程的一環？
我認為，在這個案例中，這并不真的很重要（根據我所知，libc 的 write 函數與 write 系統調用的映射相當直接）。
然而，存在不同的 libc 實現，有時它們的行為會有所不同。兩個主要的實現是 glibc（GNU libc）和 musl libc。
例如，直到最近，musl 的 getaddrinfo，這是一篇關于這個問題引發的錯誤的博客文章。
關于 stdout 和終端的小插曲
在我們的程序中，stdout（1 文件描述符）是一個終端。你可以在終端上做一些有趣的事情！例如：
- 在終端中運行
ls -l /proc/self/fd/1。我得到了/dev/pts/2的結果。 - 在另一個終端窗口中，運行
echo hello > /dev/pts/2。 - 返回到原始終端窗口。你應會看到
hello被打印出來了！
暫時就到這兒吧!
希望通過上文，你對 hello world 是如何打印出來的有了更深的了解！我暫時不再添加更多的細節，因為這篇文章已經足夠長了，但顯然還有更多的細節可以探討，如果大家能提供更多的細節，我可能會添加更多的內容。如果你有關于我在這里沒提到的程序內部調用過程的任何工具推薦，我會特別高興。
我很期待看到一份 Mac 版的解析
我對 Mac OS 的一個懊惱是，我不知道如何在這個級別上解讀我的系統——當我打印 “hello world”，我無法像在 Linux 上那樣，窺視背后的運作機制。我很希望看到一個深度的解析。
我所知道的一些在 Mac 下的對應工具：
ldd->otool -Lreadelf->otool- 有人說你可以在 Mac 上使用
dtruss或dtrace來代替strace，但我尚未有足夠的勇氣關閉系統完整性保護來讓它工作。 strace->sc_usage似乎能夠收集關于系統調用使用情況的統計信息，fs_usage則可以收集文件使用情況的信息。
延伸閱讀
一些附加的鏈接：
- 快速教程：如何在 Linux 上創建超小型 ELF 可執行文件
- 在 FreeBSD 上探索 “hello world”
- [微觀視角下的 Windows 中 “Hello World”][23A]
- 來自 LWN 的文章：如何運行程序 （以及第二部分）詳盡介紹了
execve的內部機制 - Lexi Mattick 的文章，賦予 CPU “你” 的存在
- 從零開始在 6502 上實現 “Hello, World” （來自 Ben Eater 的視頻）
