为何动态符号表需保留symbol binding？我的相关理解是否正确？

Symbol table '.dynsym' contains 139 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __ctype_toupper_loc@GLIBC_2.3 (2)
2: 0000000000000000 0 FUNC GLOBAL DEFAULT UND getenv@GLIBC_2.2.5 (3)
3: 0000000000000000 0 FUNC GLOBAL DEFAULT UND sigprocmask@GLIBC_2.2.5 (3)
...

请问我的理解是否正确？是否遗漏了symbol binding在加载/运行阶段的某些用途？

---

# 解答

你的核心理解方向是对的，但有几个细节需要修正，同时symbol binding在加载/运行阶段确实存在额外用途：

## 一、原有理解的补充修正
- **Symbol visibility并非仅由加载器处理**：可见性规则在链接阶段就会生效——链接器会根据可见性设置决定是否将符号导出到动态符号表，甚至影响符号解析的优先级。加载器只是遵循链接阶段确定的规则处理符号访问。
- **Symbol binding的作用贯穿链接与运行阶段**：绑定属性虽然在链接时确定，但加载和运行阶段依然依赖它完成关键逻辑。

## 二、Symbol binding在加载/运行阶段的具体用途
- **弱符号的运行时优先级处理**：弱绑定（WEAK）符号在加载时，如果进程中存在同名全局绑定符号，会优先使用全局符号；若没有全局符号，则使用弱符号的默认实现。动态链接器在运行时处理这一逻辑，典型场景是库提供可被用户覆盖的默认功能。
- **局部符号的运行时隔离**：局部绑定（LOCAL）符号在加载后会被限制在所属二进制文件内部，动态链接器不会将其暴露给其他模块，避免外部意外引用或覆盖，实现运行时的作用域隔离。
- **全局符号的动态重定位与共享**：全局绑定（GLOBAL）符号在加载时，动态链接器需要在整个进程的符号命名空间中找到对应定义并完成重定位。对于共享库中的全局符号，多个模块引用时会被指向同一个实例，这是运行阶段保证符号一致性的关键。

## 三、已链接文件保留binding信息的原因
动态链接器在加载和运行时仍需要依赖symbol binding信息完成符号解析、重定位和冲突处理，所以已链接二进制文件会保留这些标记。比如你用`readelf`看到的`LOCAL`/`GLOBAL`属性，就是动态链接器判断符号作用域和优先级的核心依据之一。

---

> 内容的提问来源于stack exchange，提问作者Ofek Shilon