问题标签 [symbol-table]

When I look at the symbols in my library, nm mylib.a, I see some duplicate entries that look like this:

When piped through c++filt:

What does that .eh mean, and what is this extra symbol used for?

I see it has something to do with exception handling. But why does that use an extra symbol?

(I'm noticing this with clang)

这学期我正在为我的一门课编写一个编译器，虽然我有一个符号表的工作实现，但我对它的实现有点不舒服。由于我在 Python 中进行项目，因此我决定采用 OO 方法，并且我的 AST 节点都有accept实现访问者模式的方法。我有preVisit和postVisit所有类型节点的方法，我使用它们进入/退出新范围并向表添加新绑定。它有效，但我对我的符号表是“短暂的”并绑定到这个访问者类这一事实感到不安。我通过子类化符号表访问者类来实现类型检查，并且我需要非常小心地调用超类，将它们准确地放在正确的位置。这种实现的脆弱性以及编译器的任何阶段都需要与访问者类紧密耦合的事实让我有些不安。

我想知道人们通常以哪些其他方式实现符号表？由于该信息是纯静态的，是否可以直接将其添加到 AST 节点中？有没有办法创建一个可以创建一次的表并且可以在正确的上下文中查找符号？另外，纯函数式程序员如何解决这个问题？

我正在为在 Linux 机器上运行的用 C 语言编写的应用程序实现一些有限的远程调试功能。目标是与应用程序通信并查找任意变量的值或运行任意函数。

我可以通过dlsym()调用查找符号，但我无法确定返回的地址是指函数还是变量。有没有办法通过这个符号表来确定打字信息？

我有一个过程间控制流图，我想对其执行数据流分析。我将 Hashtable 用于全局（级别 = 0）、文件（级别 = 1）和方法（级别 = 2）级别等，我从级别 0 开始将它们推送到堆栈上。

只要我在程序中只有一种方法，它就可以正常工作。但是如果我有两个方法并且假设方法1（M1）中的basicblock#2调用方法（M2），我应该如何处理这个新的方法符号表？我应该存储以前的符号表并为新方法创建一个新的符号表吗？

当调用另一个类的方法或进行嵌套函数调用时，我看到了更复杂的情况。有人可以建议我应该如何处理它吗？

我在 Java 中工作。

PS 而且我知道有一些现有的工具，如 WALA、Soot 可能适用于此，但我正在尝试了解它是如何工作的。

我有一些通过引擎 C API 与 Matlab 通信的 C++ 代码。clear我的代码在 Matlab 工作区中创建了临时变量，它会尽快通过调用对其进行清理。但是，在某些时候，我的应用程序失败了，告诉我它无法创建下一个 Matlab 临时变量（通常在 ~65530 次这样的操作之后）。

在对 Matlab 命令行进行了一些实验之后，我发现我可以在纯 Matlab 中重新创建这个问题（也就是说，独立于我的 C++ 代码及其对引擎 API 的使用）。考虑以下代码：

在我的 32 位 Windows 笔记本电脑上使用 Matlab R2008B（我知道很古老）执行此代码，循环最终中止并显示错误消息：

当前工作空间已经有太多变量；“x_65532”没有空间。

因此，似乎至少这个过时的 Matlab 版本有 64K 符号表的限制。也许对较新（64 位）版本的 Matlab 的限制更大——我很想听听其他人得到什么结果。

然而，更有趣的问题是clear调用产生了什么影响以及如何解决其奇怪的行为。这是中止前一点迭代的输出：

如您所见，whos输出清楚地表明先前迭代的临时对象已从工作区中删除，并且 clear 似乎按预期工作。尽管如此，符号表显然已经达到了容量。

所以，对于如此忠实的人来说，有两个问题：

1. 我该如何解决这个有点武断的限制？也就是说，我的clear电话应该用什么代替？
2. 更新和/或 64 位版本的 Matlab 是否改变了这种行为？

分析这个问题，我发现了一些关于dlopen在 Linux 上动态加载（）上下文中弱符号解析的行为。现在我正在寻找管理这个的规范。

让我们举个例子。假设有一个程序a可以动态加载库，b.so并c.so按此顺序。如果c.so依赖于其他两个库foo.so（实际上libgcc.so在那个例子中）和bar.so（实际上），那么通常可以使用libpthread.so导出的符号来满足. 但如果还依赖而不依赖，那么这些弱符号显然不会被联系起来。似乎inkages 只从它们的所有依赖项中寻找符号。bar.sofoo.sob.sofoo.sobar.sobar.sofoo.soab.so

这在某种程度上是有道理的，因为否则加载c.so可能会改变已经使用该库foo.so的某个点的行为。b.so另一方面，在让我开始的问题中，这引起了很多麻烦，所以我想知道是否有办法解决这个问题。为了找到解决方法，我首先需要很好地了解在这些情况下如何指定符号解析的非常准确的细节。

在这些场景中定义正确行为的规范或其他技术文档是什么？

我知道我们可以通过读取符号表来获取 elf 中用户定义函数的开始地址，就像下面的函数 main 和 foo：

但是如何获取某些函数的结束地址呢？

谁能给我一些帮助？谢谢！

我想知道是否只有一个符号表存储有关源文件的所有信息，或者有多个相互堆叠的符号表，并且仅在当前范围与表相关时才获取。

例如说我有两种方法

这里两个中的a和b的作用域不同，所以如果符号表是堆叠的，则在执行foo时会先获取与foo关联的符号表。但是在执行 bar 时，bar 的符号表会堆叠在 foo 上，因此当前符号表包含 bar 的 a 和 b 的信息。

如果符号表是集中式的，则 foo 的 info 和 bar 的 info 都驻留在一个符号表中，但可能有条目指定 foo 中的 a,b 属于 foo 的范围，而 bar 中的 a,b 属于 bar。没有其他符号表可供参考

以上是我对符号表的假设。请告诉我哪一个是真实案例，并填写可能更多的细节。

谢谢

I have successfully built and installed Ian Buclaw's (ibuclaw) GDB branch on github on my Ubuntu 13.10 x86_64 with its default compiler GCC 4.8.1.

I had to remove the file ld from the bin sub-directory otherwise DMD complains about a sysroot thing in link phase.

When I then compile my test program and run it through GDB I have problems.

I can do break main, run and GDB stops at the beginning of main but when I do next I get the following undesired output

Isn't ibuclaw's GDB supposed to work here?

My test program was compiled as

without any warnings nor errors. I've also tried to pretend to be C

with same result.

Further when I do b followed by tab, most of the symbols in the completion list are not demangled.

My test program looks like

测试平台为 32 位 Linux。

我编译ac程序时不剥离符号信息，使用objdump反汇编elf可执行文件。

这是部分结果。

如果我使用：

删除符号信息并使用 objdump 再次反汇编 elf 可执行文件，我仍然可以看到如下结果：

所以我的问题是：

在我剥离了所有符号信息之后，像objdump这样的反汇编工具如何知道某些库函数的名称..？

谢谢！