远程事后核心转储分析，无需共享系统库的精确调试符号
您通常如何解决这个问题？想象一下，一个线程在 Computer1 上的 libc 代码（系统共享库）内部崩溃，然后生成核心转储。但要分析此 coredump 的 Computer2 可能具有不同版本的 libc。
那么：
在远程计算机上拥有相同的共享库有多重要？如果计算机 2 上没有完全相同版本的 libc，gdb 是否会正确重建堆栈跟踪？
拥有正确的 libc 调试符号有多重要？如果 Computer2 上没有完全相同的调试符号，gdb 会正确重建堆栈跟踪吗？
避免共享系统库的调试符号不匹配问题的“正确”方法是什么？对我来说，似乎没有单一的解决方案可以优雅地解决这个问题？也许任何人都可以分享他的经验？
How do you usually get around this problem? Imagine that a thread crashes inside libc code (which is a system shared library) on Computer1 and then generates a coredump. But the Computer2 on which this coredump will be analysed might have a different version of libc.
So:
How important it is to have the same shared library on the remote computer? Will the gdb correctly reconstruct stacktrace without having exact same version of libc on Conputer2?
How important it is to have correct debug symbols for libc? Will the gdb correctly reconstruct stacktrace without having exact same debug symbols on the Computer2?
And what is the "correct" way to avoid this debug symbol mismatch problem for shared system libraries? For me it seems that there is no single solution that solves this problem in an elegant way? Maybe anyone can share his experience?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这要看情况。在某些处理器上，例如
x86_64，正确的 unwind GDB 需要描述符 才能正确展开堆栈。在这样的机器上，使用不匹配的 libc 分析 coredump 可能会产生完整的垃圾。您不需要 libc 的调试符号来获取堆栈跟踪。如果没有调试符号，您将无法获得文件和行号，但您应该获得正确的函数名称（除非发生内联）。
你的问题的前提是错误的——调试符号与此无关。当在 C1 上生成 coredump 时，分析 C2 上的 coredump 的“正确”方法是拥有 C1 库的副本（例如
/tmp/C1/lib/...）并直接GDB 使用该副本而不是 C2 已安装的libc(gdb) set solib-absolute-prefix /tmp/C1命令
。 注意：在将核心加载到 GDB 之前，上述设置必须生效。这：
将不起作用（在设置生效之前读取核心）。
这是正确的方法：（
我试图在网上找到对此的参考，但没有）。
什么是展开描述符？
在没有帧指针的情况下编译代码时需要展开描述符（优化模式下 x86_64 的默认设置）。此类代码不会保存 %rbp 寄存器，因此需要告诉 GDB 如何从当前帧“后退”到调用者帧（此过程也称为堆栈展开）。
为什么C1的libc.so不包含在核心中？
核心文件通常只包含程序地址空间可写段的内容。只读段（可执行代码和展开描述符所在的位置）通常不是必需的——您可以直接从磁盘上的 libc.so 读取它们。
但当你在 C2 上分析 C1 的核心时，这不起作用！
一些（但不是全部）操作系统允许配置“完整核心转储”，其中操作系统也会转储只读映射，这样您就可以准确地分析任何计算机上的核心。
It depends. On some processors, such as
x86_64, correct unwind descriptors are required for GDB to properly unwind the stack. On such machine, analyzing coredump with non-matching libc will likely produce complete garbage.You don't need debug symbols for libc to get the stack trace. You wouldn't get file and line numbers without debug symbols, but you should get correct function names (except when inlining has taken place).
The premise of your question is wrong -- debug symbols have nothing to do with this. The "correct" way to analyze coredump on C2, when that coredump was produced on C1, is to have a copy of C1's libraries (in e.g.
/tmp/C1/lib/...) and direct GDB to use that copy instead of the C2's installedlibcwith(gdb) set solib-absolute-prefix /tmp/C1command.
Note: above setting must be in effect before you load the core into GDB. This:
will not work (core is read before the setting is in effect).
Here is the right way:
(I've tried to find a reference to this on the web, but didn't).
What are unwind descriptors?
Unwind descriptors are required when code is compiled without frame pointers (default for x86_64 in optimized mode). Such code does not save %rbp register, and so GDB needs to be told how to "step back" from current frame to the caller frame (this process is also known as stack unwinding).
Why isn't C1's libc.so included in the core?
The core file usually contains only contents of writable segments of the program address space. The read-only segments (where executable code and unwind descriptors reside) is not usually necessary -- you could just read them directly from libc.so on disk.
Except this doesn't work when you analyze C1's core on C2!
Some (but not all) operating systems allow one to configure "full coredumps", where the OS will dump read-only mappings as well, precisely so you can analyze core on any machine.