我有一个核心文件，想调试dlopen() 返回的句柄，例如验证它仍然完好无损。在句柄上调用的dlsym() 函数在堆栈跟踪中指示this=0x0。是否有关于 dlopen() 句柄背后的描述？还是我必须检查libdl.so 源代码？
【问题讨论】：
core 文件包含一些关于 dlopen 的痕迹 - 它知道哪些文件是 mmap-ed-
this=0x0 通常表示静态对象尚未初始化。如果不了解您的代码，很难说这是否是问题所在。另见C++ FAQ | Static initialization order fiasco。
Dlopen 返回 NULL 如果它未能找到或加载库（在这种情况下，您不需要调试任何其他内容）或指向在公共 Glibc 头 link.h 中定义的 link_map 数据结构的指针（参见 @例如 987654321@）。
【讨论】：
dlopen(3) 可能会失败，在这种情况下会给出NULL。您应该始终针对此类故障进行测试（请参阅this）。我猜有些dlopen 在你的情况下失败了，但你忘了测试它（这可以解释gdb 在dlsym 中报告的this=0）。但是，在 Linux 上，您可以成功地完成数十万次 dlopen-s，请参阅我的 manydl.c 示例。当然，您不应该将dlsym(3) 与NULL 共享对象句柄一起使用（否则它是undefined bahavior，可能是segmentation fault）。
要查找，特别是在 Linux 上，给定它可能属于哪个函数的地址，您可以使用 dladdr(3)。
注意core(5) 文件知道mmap-ed 内存段（除非它们可能不完整，因为您使用RLIMIT_CORE 达到了setrlimit(2) 设置的一些限制）
另见proc(5)。如果您可以将错误重现到某个进程 1234 中，请在该进程仍处于活动状态时查看 /proc/1234/maps。
dlopen() 句柄后面有什么描述吗？
它是一些abstract data type（仅用于dlopen、dlsym、dlclose 和dlinfo(3)...另见dl_iterate_phdr(3)。），因此可移植程序不需要关心.当然，您可以研究dlopen 的实现，例如GNU libc 的内部源代码。另请参阅您系统的/usr/include/link.h 及其struct link_map（感谢yugr 评论）
【讨论】：