再次实现了一个Lua性能分析器
内容提要
作者开发了一个基于eBPF的Lua性能分析器，采用栈采样技术，对目标程序无侵入，且目标程序死循环时仍可运行。核心难点是手动栈回溯：因编译器优化抹去栈帧指针，作者利用ELF的eh_frame段和CFI指令，预处理后供BPF二分查找，并完成PC到VA的转换。Lua调用栈通过遍历L->ci链表获取，用字符串映射表压缩文件信息。还实现了自定义栈哈希统计以生成火焰图，并处理了Lua 5.4的C函数yield匹配问题。
延伸解读
无侵入采样的代价与取舍
作者选择在BPF程序内完成栈回溯，而非将栈数据复制到用户空间用libunwind处理。这避免了ringbuffer异步性导致Lua调用栈与C调用栈不匹配的问题，也符合eBPF在内核侧加工数据的思路。但代价是BPF程序需自行处理eh_frame和CFI指令，并应对校验器的严格检查，实现复杂度显著上升。
eh_frame与地址转换的实际难点
利用eh_frame进行栈回溯需将ELF中的PC转换为进程空间的VA。作者通过Program Header Table和/proc/<pid>/smaps的映射信息进行转换，但文末试用反馈指出smaps中的offset会按4K对齐，与ELF offset不完全一致，导致匹配失败。这说明该转换逻辑对文件映射细节敏感，实际部署时需处理对齐差异。
Lua栈压缩与哈希冲突的权衡
为节省BPF栈空间，作者用字符串映射表将文件路径转为uint32_t id，再与行号合成虚拟地址。该方法依赖Lua源文件TString指针常驻的特性，将指针视为哈希值，冲突时由用户空间接管旧字符串。这降低了存储开销，但冲突处理增加了用户空间交互，且合成地址依赖bit63为0的假设。
C函数yield带来的合并挑战
Lua 5.4允许在C函数中yield，导致L->ci链表中可能出现C函数或闭包，而C调用栈中无对应信息。作者采用启发式匹配：当L->ci中的C函数与C调用栈中的C函数匹配时，认为从Lua栈顶到该位置的部分由当前C调用栈产生并合并。这种策略在复杂yield场景下可能不够精确，是分析器的一个已知局限。
Q&A
这个Lua性能分析器是基于什么技术实现的？
基于eBPF和栈采样技术，对目标程序无侵入，且目标程序死循环时仍可运行。
为什么作者要手动进行栈回溯？
因为现代编译器优化默认抹去栈帧指针，而eBPF内置API只能在保留栈帧指针时获取调用栈。为了不对目标程序造成侵入（如强制使用-fomit-frame-pointer），作者选择手动栈回溯。
如何利用eh_frame进行栈回溯？
eh_frame包含CFI指令，用于指导栈回溯。作者预处理eh_frame，模拟CFI指令执行，生成每行汇编对应的寄存器回溯信息，供BPF程序二分查找快速获取回溯规则。
如何处理Lua调用栈中的文件信息以避免空间浪费？
在BPF程序中创建字符串映射表strings，将文件路径字符串转换为uint32_t类型的id，然后用id和行号组合成虚拟地址（通过位标记区分），从而压缩存储空间。
如何生成火焰图？
自定义栈哈希统计：定义stacks哈希表，计算内核空间、用户空间和Lua调用栈的哈希值，根据哈希值确定槽位，比较调用栈是否相同并计数，最终将统计结果发送回用户空间生成火焰图。
Lua 5.4的C函数yield导致什么问题？如何解决？
Lua 5.4支持在C函数中yield，可能导致L->ci链表中的C函数在C调用栈中不存在。解决方案是采用启发式匹配策略：当L->ci中的C函数与C调用栈中的C函数匹配时，认为从Lua栈顶到该C函数的部分由当前C调用栈产生，并进行合并。
