为什么Linux进程虚拟地址空间中存在多个libc、ld、bash及动态库映射条目

问题原因可分为两部分解释： #

1. 单个二进制文件（bash或任意.so）存在多个映射条目的原因 #

操作系统加载ELF格式的可执行文件/动态库时，会按照段（Segment）的权限拆分映射，不会把整个文件映射为连续的一块虚拟地址，这是出于内存保护和资源复用的设计：

• 代码段（Text段）：权限为r-x，只读可执行，对应文件中存储可执行指令的部分，所有使用该二进制的进程可以共享这部分物理内存，大幅节省内存开销
• 只读数据段（Rodata段）：权限为r--，只读不可执行，存储常量字符串、const修饰的全局变量等只读数据
• 数据段（Data段）：权限为rw-p，可读写，对应文件中存储已初始化的非const全局变量的部分，这部分是进程私有映射，修改不会影响其他使用同一个二进制的进程
• BSS段：权限为rw-p，通常映射无对应磁盘文件的匿名内存（你可以看到对应条目的设备号为00:00），用于存储未初始化的全局变量，加载时内核会自动填充0，不需要占用磁盘空间
• 你看到的权限为---p的段是内存防护页，用于拦截越界内存访问，一旦程序访问该区域会直接触发段错误，避免非法访问扩散

你示例中的bash就拆分了三个映射：第一个r--p是只读段，第二个rw-p是数据段，第三个无文件名的rw-p就是bash的BSS段。每个.so的拆分逻辑完全一致，因此每个动态库都会对应多个不同权限的映射条目。

2. 地址空间中存在多个.so动态库的原因 #

bash作为功能复杂的交互式shell，没有将所有依赖的功能都静态编译进自身二进制，而是通过动态链接的方式复用通用系统库，减少自身体积、方便库版本升级：

• libc-2.29.so是GNU C标准库，几乎所有Linux用户态程序都依赖该库，提供内存分配、文件操作、字符串处理、系统调用封装等基础能力
• libdl-2.29.so是动态链接操作库，提供动态加载、查找其他动态库符号的接口
• libtinfo.so.5.9是终端信息处理库，提供终端光标控制、颜色输出、快捷键解析等终端交互相关的能力
• ld-2.29.so是Linux系统的动态链接器本身，内核启动bash进程时会优先加载该链接器，由它完成所有bash依赖动态库的加载、符号重定位工作，之后才会运行bash本身的代码

内容的提问来源于stack exchange，提问作者md.jamal