Linux中國

Linux 下「Hello World」的幕後發生了什麼

222 views0
By
Share

今天我在想 —— 當你在 Linux 上運行一個簡單的 「Hello World」 Python 程序時，發生了什麼，就像下面這個？

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 到底做了什麼？當你的操作系統要打開一個文件時，主要分為兩個步驟：

  1. 它將 文件名 映射到一個包含該文件元數據的 inode
  2. 它利用這個 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) = 3708100

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

這裡有些工具可以查看進程的相關信息：

  • pstree 會展示你的系統中所有進程的樹狀圖
  • cat /proc/PID/stat 會顯示一些關於該進程的信息。你可以在 man proc 中找到這個文件的內容說明。例如，第四個欄位是父進程的PID。

新進程的繼承

新的進程（即將變為 python3 的）從 Shell 中繼承了很多內容。例如，它繼承了：

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

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

從這段內容中，我理解到：

  1. 請求內核運行 /lib64/ld-linux-x86-64.so.2 來啟動這個程序。這就是所謂的動態鏈接器，我們將在隨後的部分對其進行討論。
  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, "177ELF2113>1 l"..., 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 worldn", 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 並不支持 TCP DNS，這是一篇關於這個問題引發的錯誤的博客文章。

關於 stdout 和終端的小插曲

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

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

暫時就到這兒吧!

希望通過上文，你對 hello world 是如何列印出來的有了更深的了解！我暫時不再添加更多的細節，因為這篇文章已經足夠長了，但顯然還有更多的細節可以探討，如果大家能提供更多的細節，我可能會添加更多的內容。如果你有關於我在這裡沒提到的程序內部調用過程的任何工具推薦，我會特別高興。

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

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

我所知道的一些在 Mac 下的對應工具：

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

延伸閱讀

一些附加的鏈接：

（題圖：MJ/b87ed0a2-80d6-49cd-b2bf-1ef822485e3f）

via: https://jvns.ca/blog/2023/08/03/behind--hello-world/

作者：Julia Evans 選題：lujun9972 譯者：ChatGPT 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive

對這篇文章感覺如何？

太棒了
0
不錯
0
愛死了
0
不太好
0
感覺很糟
0
雨落清風。心向陽
    Previous
    Next

    You may also like

    Leave a reply

    您的電子郵箱地址不會被公開。 必填項已用 * 標註

    此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據。

    More in:Linux中國