在跟踪内核的状态之前，需要利用内核提供的调试信息查询内核函数、内核跟踪点以及性能事件等。类似地，在跟踪应用进程之前，也需要知道这个进程所对应的二进制文件中提供了哪些可用的跟踪点。那么，从哪里可以找到这些信息呢？如果使用 GDB 之类的应用调试过程序，那就是应用程序二进制文件中的调试信息。
在静态语言的编译过程中，通常你可以加上 -g 选项保留调试信息。这样，源代码中的函数、变量以及它们对应的代码行号等信息，就以 DWARF（Debugging With Attributed Record Formats，Linux 和类 Unix 平台最主流的调试信息格式）格式存储到了编译后的二进制文件中。
有了调试信息，你就可以通过 readelf、objdump、nm 等工具，查询可用于跟踪的函数、变量等符号列表。比如，使用 readelf 命令，查询二进制文件的基本信息。在终端中执行下面的命令，就可以查询 libc 动态链接库中的符号表：
# 查询符号表（RHEL8系统中请把动态库路径替换为/usr/lib64/libc.so.6） readelf -Ws /usr/lib/x86_64-linux-gnu/libc.so.6 # 查询USDT信息（USDT信息位于ELF文件的notes段） readelf -n /usr/lib/x86_64-linux-gnu/libc.so.6
除了符号表之外，理论上可以把 uprobe 插桩到二进制文件的任意地址。不过这要求你对应用程序 ELF 格式的地址空间非常熟悉，并且具体的地址会随着应用的迭代更新而发生变化。所以，在需要跟踪地址的场景中，一定要记得去 ELF 二进制文件动态获取地址信息。
另外需要提醒的是，uprobe 是基于文件的。当文件中的某个函数被跟踪时，除非对进程 PID 进行了过滤，默认所有使用到这个文件的进程都会被插桩。
这些查询跟踪点信息的方法很可能是跟编程语言相关的。如果把常用的编程语言进行归类，按照其运行原理，我认为大致上可以分为三类：
- 第一类是 C、C++、Golang 等编译为机器码后再执行的编译型语言。这类编程语言开发的程序，通常会编译成 ELF 格式的二进制文件，包含了保存在寄存器或栈中的函数参数和返回值，因而可以直接通过二进制文件中的符号进行跟踪。
- 第二类是 Python、Bash、Ruby 等通过解释器语法分析之后再执行的解释型语言。这类编程语言开发的程序，无法直接从语言运行时的二进制文件中获取应用程序的调试信息，通常需要跟踪解释器的函数，再从其参数中获取应用程序的运行细节。
- 最后一类是 Java、.Net、JavaScript 等先编译为字节码，再由即时编译器（JIT）编译为机器码执行的即时编译型语言。同解释型语言类似，这类编程语言无法直接从语言运行时的二进制文件中获取应用程序的调试信息。跟踪 JIT 编程语言开发的程序是最困难的，因为 JIT 编译的状态只存在于内存中。
编程语言的类型对 eBPF 跟踪也有非常大的影响，不同类型编程语言开发的应用程序，其跟踪过程和难度也不相同。
由于可以直接从调试信息中获取到符号（用于跟踪函数）和帧指针（用于跟踪调用栈），编译型语言开发的应用程序是比较容易跟踪的。
在跟踪函数参数和返回值时，你需要首先区分编程语言的调用规范，然后再去寄存器或堆栈中读取函数的参数和返回值。
此外，调试信息并非一定要内置于最终分发的应用程序二进制文件中，它们也可以放到独立的调试文件存储。为了减少应用程序二进制文件的大小，通常会把调试信息从二进制文件中剥离出来，保存到 <应用名>.debuginfo 或者 <build-id>.debug 文件中，后续排查问题需要用到时再安装。
比如，在 RHEL 和 Ubuntu 等常见的 Linux 发行版中，调试信息跟应用程序通常是两个不同的软件包。而对很多开发者来说，每次编译和发布应用程序之前，通常都需要执行一下 strip 命令，把调试信息删除后才发布到生产环境中。
这里给个小提示：ELF 符号表包含 .symtab（应用本地的符号）和 .dynsym（调用到外部的符号），strip 命令实际上只是删除了 .symtab 的内容。
对于各种解释型编程语言的二进制文件（如 Python、PHP 等），你可以使用类似编译型语言应用程序的跟踪点查询方法，查询它们在解释器层面的 uprobe 和 USDT 跟踪点。比如，对于 Python3 来说，你可以执行下面的命令查询：
sudo bpftrace -l '*:/usr/bin/python3:*'
命令执行后，你会得到 1500 多个跟踪点。接下来的难点在于，如何从这些解释器的跟踪点中找出应用程序的函数信息，所以你需要对解释器的运行原理有一定的了解。
还有一种是 Java、.Net 等即时编译型语言。对于这类编程语言开发的应用程序，应用源代码会先编译为字节码，再由即时编译器（JIT）编译为机器码执行。以 Java 为例，Java 虚拟机（JVM）除了会执行常规的 JIT 即时编译之外，还会在执行过程中对运行流程进行剖析和优化，因而也加大了跟踪的难度。
同解释型编程语言类似，uprobe 和 USDT 跟踪只能用在即时编译器上，从即时编译器的跟踪点参数里面获取最终应用程序的函数信息。由于 USDT 跟踪点比 uprobe 更为稳定，如果编程语言提供了 USDT 跟踪功能，推荐打开 USDT 跟踪（比如 Java 需要打开 --enable-dtrace 编译选项），再利用 USDT 而不是 uprobe 去跟踪应用的执行过程。
要找出即时编译器的跟踪点同应用程序运行之间的关系，就需要你对编程语言的底层运行原理非常熟悉，这也是跟踪即时编译型语言应用程序最难的一步。不过这一步梳理清楚之后，具体的跟踪步骤与解释型编程语言应用程序是类似的。
