从交叉编译的linux目标分析崩溃转储

我在分析在我无法访问的linux机器上生成的崩溃转储时遇到了一个问题。情况如下：

开发是在运行Ubuntu 14.04、13.10和14.04等发行版的Linux机器上进行的。 目标是一个基于x86的嵌入式系统，它运行在剥离的 下Debian 5 目标的构建发生在其中一台开发机器上，具体取决于发布者。我们使用chroot环境进行交叉构建，我们非常确定chroot环境是通过git控制的同一版本 顺便说一下，软件是用C++编写的。p> 现在，软件有时会在我们无法复制的情况下崩溃，因此我们的用户会通过电子邮件向我们发送一个核心文件。该计划如下所示：

在chroot环境中使用调试符号编译相同版本的软件 查看带有GDB的核心文件，也在chroot环境中。 除一个问题外，这通常工作正常。只有在剥离的二进制文件和构建的二进制文件在同一台机器上进行调试时，它才起作用。在其他机器上，调试器似乎很混乱，stacktrace可能由完全不相关的调用组成，这些调用没有任何意义。这是一件我们一直在思考的事情，现在还没有结论。这也是一种我们可以轻松应对的情况

但是后来在我的机器上进行了一些无意识的升级，升级到一个新的发行版，使我构建的目标中的所有核心文件都无用

现在，我正在寻找一种方法来理解正在发生的事情，并寻找一种方法来交叉调试在机器上生成的核心文件，而不需要远程访问运行不同Linux发行版的机器。如果我们做了一些根本错误的事情

只有在剥离的二进制文件和构建的二进制文件在同一台机器上进行调试时，它才起作用。 a了解正在发生的事情

很明显，尽管你相信你有一个封闭的构建环境，但事实上你没有。如果您确实有一个完全封闭的构建环境，那么在不同的机器上构建就不重要了

因此，您的第一步应该是找到并消除所有非密封的内容，直到您可以在构建版本的每台机器上构建完全相同的版本

一旦你做到了这一点，它也应该解决你的b问题

如果我们做了一些根本错误的事情

---

您似乎犯了根本错误，因为您相信您的chroot是受版本控制的，而它显然不是。

找到它了！谢谢你指出了正确的方向。该项目由一个makefile编译，该makefile在早期阶段通过调用find查找所有需要编译的对象。事实证明，在我可以测试的所有机器上，所有对象的编译都是完全相同的。但由于find不会以保证的顺序返回其结果，因此对象移交给链接器的顺序并不总是相同的。通过管道将查找结果排序解决了这个问题。在所有可用于测试的机器上，构建结果现在都有点相同。