直接调用unw_get_reg拿不到正确rip/pc，是因为unw_getcontext在信号处理或异常中途捕获时无法反映真实调用点，尤其在sigaltstack触发的sigsegv中寄存器状态常已偏移；必须改用unw_init_local（同步调用）或unw_init_remote（信号上下文），后者需配合sa_siginfo和ucontext_t手动传入，且不可依赖unw_getcontext初始化cursor。
为什么直接调用 unw_get_reg 拿不到正确的 RIP 或 PC
libunwind 默认使用“当前上下文”（unw_getcontext）初始化，但这个函数在信号处理或异常中途捕获时可能无法反映真实调用点——尤其在 sigaltstack 上触发的 SIGSEGV 中，unw_getcontext 保存的寄存器状态常已偏移。必须改用 unw_init_local（对同步调用）或 unw_init_remote（对信号上下文），后者需配合 sigaltstack + ucontext_t 手动传入。
实操建议：
- 普通函数内回溯：用
unw_init_local(&cursor, &uc)，其中&uc是通过getcontext(&uc)获取的； - 信号处理中回溯：在信号 handler 入口立即调用
unw_init_remote(&cursor, &uc)，&uc来自 handler 第二个参数sigaction的siginfo_t*和ucontext_t*（注意：Linux 下需启用SA_SIGINFO并用sigaction注册）； - 别直接用
unw_getcontext初始化 cursor——它不保证栈帧完整性，尤其在优化开启（-O2）时易跳过内联帧。
如何避免 unw_step 在内联函数或尾调用处提前终止
libunwind 默认只解析有完整调试信息（DWARF）和 .eh_frame 的帧。GCC/Clang 编译时若未加 -g 或 -fexceptions，unw_step 可能在内联展开点或 tail-call 优化后的位置停住，表现为只看到 2–3 层堆栈。
实操建议：
- 编译时必须加
-g（生成 DWARF）和-fno-omit-frame-pointer（禁用帧指针省略，否则 libunwind 依赖的RBP链失效）； - 若用 Clang，额外加
-funwind-tables（确保 .eh_frame 存在）； - 测试时先关掉优化：
-O0，确认回溯正常后再逐步开-O1，避免误判是代码问题而非编译配置问题； -
unw_step返回 0 表示到底（unw_is_signal_frame为 0），返回负值才是错误；别把 0 当失败处理。
怎么安全地把 unw_word_t 地址转成可读函数名（含符号+偏移）
libunwind 只提供原始地址（unw_word_t），直接用 dladdr 解析可能失败：它不支持 PIE 可执行文件的地址重定位，也不处理 C++ 符号修饰。必须结合 libbacktrace 或手动用 addr2line（调试时）、或预加载 .symtab（生产环境）。
实操建议：
- 开发阶段：用
addr2line -e ./your_binary -f -C 0xADDR验证地址是否可解； - 运行时解析：优先用
backtrace_symbols（glibc 提供，轻量但无 demangle）+abi::__cxa_demangle手动解码 C++ 名； - 别依赖
unw_get_proc_name返回干净名字——它在无调试信息时返回空或截断名，且不自动 demangle； - 若程序动态链接大量 SO，注意
dladdr只查本模块，跨模块地址需先用dladdr定位 so 路径，再用libbfd或libdw查符号。
为何多线程环境下 unw_step 偶尔卡死或返回 -UNW_ESTOP
libunwind 不是完全线程安全的：内部缓存（如 dwarf parser state）在多线程并发调用同一 cursor 时可能冲突；更常见的是，某个线程正在修改栈（如 mmap/guard page 触发、栈溢出重分配），导致 unw_step 读到非法内存并触发 UNW_ESTOP。
实操建议：
- 每个线程独立声明
unw_cursor_t cursor，绝不共享； - 避免在 signal handler 里做复杂操作（如 malloc、printf），只记录地址数组，留到主线程处理；
- 若用
unw_backtrace（封装版），注意它内部调用unw_init_local+ 循环unw_step，仍受上述限制； - 生产环境建议加超时保护：用
clock_gettime(CLOCK_MONOTONIC)记录起始时间，每步unw_step后检查是否超 1ms，超则中断——栈深通常 ≤100，卡住基本是栈损坏。
最麻烦的不是写不对，而是编译选项和信号上下文传递漏一环，结果在 release 版里堆栈全空。调通前务必用 readelf -S binary | grep -E "(debug|eh_frame)" 确认段存在，再用 objdump -d binary | grep -A20 "main:" 看帧指针是否真被保留。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
