C++ 编译器创建的符号表答案

【问题标题】：Symbol Table created by the C++ compilerC++ 编译器创建的符号表
【发布时间】：2014-10-22 19:38:48
【问题描述】：

我正在阅读 Effective C++，第 3 版和第 2 项（更喜欢 const、枚举和内联而不是#defines），Scott Meyers 提到了 符号表：他解释说#defines可能不会出现在符号表中。

根据here的答案、reading的一些建议以及Wikipedia的文章，我将符号表定义如下：由于编译器只为每个翻译单元创建目标文件，我们仍然需要一种方法来引用翻译单元之间的符号。这是使用为每个目标文件创建的表来完成的，以便可以在稍后阶段定义符号 - 在从目标文件创建可执行文件/库时由链接器定义。在链接过程中，符号被链接器替换为相应的内存地址。

以下是我想知道的：

我上面的解释正确吗？
链接后，一旦内存地址被解析，我认为不需要符号表吗？也就是说，我认为符号表在可执行文件/库中不可用；对吗？
我怀疑符号表对其他编译器任务也有用？可能是识别命名冲突之类的东西？
上述符号表与export table不同。至少在 Visual C++ 的上下文中，导出表定义了在库外显式声明为可见的符号。我想在某种意义上这是一个符号表——但与 Scott 所指的符号表无关。
符号表还有什么有趣的地方吗？也就是说，我应该有关于符号表的任何其他见解吗？

感谢您的时间和贡献。

【问题讨论】：

标签： c++ visual-c++ compiler-construction symbols effective-c++

【解决方案1】：

编译器都存在符号表（然后编译器甚至将局部变量符号放入其中；即使preprocessor 也有某种符号表用于#define-d 名称，但预处理器可能在编译器内部今天）和链接器。但这些是不同的表格，组织方式不同。

链接器符号表主要用于导出或导入的全局符号。请注意linker 执行一些relocation。请注意，链接器在 Windows 和 Linux 上的行为完全不同（dllimport 在 Windows 上，__attribute__(visibility...) 在 Linux 上）。请注意，对于动态库，一些链接发生在运行时 (dynamic loading)。对于 C++，name mangling 可能会发生。阅读vague linkage和template instantiation和link-time optimization GCC...

另请阅读Levine's book: Linkers and Loaders 和例如ELF 格式的维基页面（用于 Linux 和许多 Unix 系统上的目标文件、共享库和可执行文件）。

如果您可以访问某些 Linux 系统，请使用 readelf(1)、nm(1) 和 objdump(1) 实用程序。另请阅读Drepper's paper: How To Write Shared Libraries（在 Linux 上）

【讨论】：