Linux 下“Hello World”的幕后发生了什么

今天我在想 —— 当你在 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 '\0' '\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, "\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

所以它在调用
__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并不支持 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则可以收集文件使用情况的信息。