ltrace(库跟踪工具)如何工作? [英] How does ltrace (library tracing tool) work?

问题描述

ltrace 是如何工作的?

How ltrace works?

它是如何发现程序调用库函数的?

How does it find out that program's calling library functions?

是否有任何对库函数的调用都通过的通用代码路径?也许 ltrace 是在这个常用的代码路径中设置断点?

Is there any common code path that all calls to library functions come through? Maybe ltrace is setting breakpoint in this common code path?

谢谢！

推荐答案

当解析需要连接到库函数的引用时，动态可执行文件有一个链接器使用的符号表.(您可以通过运行 objdump -T/path/to/binary 自己查看).

Dynamic executables have a symbol table used by the linker when resolving references that need to be connected to library functions. (You can see this yourself by running objdump -T /path/to/binary).

这个符号表也可以被其他工具访问——比如 ltrace——，因此确定哪些函数需要挂钩并单独遍历该列表很简单.

This symbol table is accessible by other tools -- such as ltrace -- as well, so it's trivial to determine which functions need to be hooked and walk that list individually.

请参阅 关于 ltrace 内部结构的演讲在 Ottowa Linux Symposium 上发表，其中提供了详细的功能细分；要跟踪源代码，请参阅官方存储库，或第三方github镜像.

See a talk on ltrace internals presented at the Ottowa Linux Symposium, which provides a detailed, function-by-function breakdown; to follow along the source, see the official repository, or a third-party github mirror.

一些较新的版本(比那次演讲更近)也挂钩了 dlopen() 调用，以便也能够跟踪动态加载的库的调用.想一想，那里的机制应该是相当明显的——如果可以用一个 shim 替换 dlopen()(当 dlopen() 本身像上面那样动态链接时)，然后可以在它返回的任何函数指针上设置断点.

Some newer releases (more recent than that talk) also hook the dlopen() call, to be able to trace invocation of dynamically loaded libraries as well. The mechanism there should be rather obvious on a moment's thought -- if one can replace dlopen() with a shim (when dlopen() itself is dynamically linked as above), one can then set a breakpoint on any function pointer it returns.

这篇关于ltrace(库跟踪工具)如何工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！