用bt查看调用栈可确认回调函数的直接调用者，即栈帧第二层函数；需结合frame切换、info symbol、info proc mappings等命令应对优化、动态库或栈破坏等情况，并追溯注册逻辑以理解调用根源。
用 bt 看调用栈，确认回调函数的直接调用者
回调函数本身没有“主动调用”行为，它总是在某个上下文中被第三方代码（比如库、框架或系统）调用。GDB 中最直接的办法就是：在回调函数入口处打断点，等它被触发后立刻执行 bt（backtrace）。输出的栈帧顶部是回调函数自己，第二层就是实际调用它的函数——这个函数名通常就是注册回调时传入的“宿主”或“事件分发器”。
常见陷阱是只看 bt 最上两行，却忽略中间可能存在的间接层（比如 GDB 的 event_handler 包装器、Pwndbg 的钩子调度函数、或 C 语言中通过函数指针间接跳转的中间函数）。此时需要逐层用 frame N 切换并检查 info registers 或 x/2i $rip-2 查看返回地址附近的指令。
在回调函数里用 info proc mappings + x/i 定位调用来源模块
当 bt 显示不完整（比如栈被破坏、优化导致内联、或回调由动态加载的 so 触发），可结合内存布局判断调用者归属：
- 运行
info proc mappings，找到当前回调函数所在地址对应的映射段（注意看起始地址是否落在libc、libpthread、your_lib.so或主程序段） - 用
x/i $rbp-8（x86_64）或x/i $r11（ARM64）读取调用返回地址，并用info symbol 0x...反查符号名 - 若返回地址落在未知区域（比如堆上的一段 jit code 或 mmap 分配的可执行页），说明可能是自定义事件循环或 JIT 引擎触发的回调，需配合源码确认注册逻辑
用 break *callback_name + disassemble $pc-10,$pc+10 查看调用指令模式
某些回调不是通过标准 call 指令进入的（比如信号处理函数、ptrace 事件回调、或 ARM 的 BLX 指令跳转），此时仅靠 bt 可能漏掉关键上下文。更稳妥的做法是：
- 对回调函数地址下硬件断点：
hb *callback_name（避免被优化跳过） - 命中后立即执行
disassemble $pc-10,$pc+10，观察断点前几条指令是否为call、bl、jmp或ret，再结合x/xg $rsp（x86_64）看栈顶是否存有有效返回地址 - 特别注意：如果回调是通过
pthread_create启动的新线程入口、或signal注册的 handler，bt会显示start_thread或__restore_rt，这时要回溯到pthread_create的第三个参数（start_routine）或sigaction的sa_handler字段值
结合源码和 info functions 确认回调注册点
很多回调的触发源头不在当前调用栈里，而是在初始化阶段注册的。比如 Pwndbg 的 @event_handler(EventType.STOP)、Linux 内核模块的 register_kprobe、或用户代码里的 qsort(..., compare_func)。这类情况不能只依赖运行时栈：
- 先用
info functions callback_name确认该符号是否被多个模块定义（避免调试了错误的副本） - 搜索源码中所有对
callback_name的引用：谁把它传给了qsort、signal、atexit、SetTimer或自定义注册 API？ - 如果用了 GDB Python 扩展（如 Pwndbg），检查
pwndbg.gdblib.events.registered字典内容，它会记录每个事件类型绑定的回调函数对象及其注册位置
真正难的不是看到“谁调了回调”，而是理解“为什么是它来调”——这往往取决于你用的是哪个库、事件模型是同步还是异步、以及注册时有没有做 wrapper 封装。别只盯着栈帧，注册逻辑和事件分发路径才是根因。
