LLDB无法列出函数、断点未触发及多位置异常问题求助

替代GDB info functions的LLDB命令 #

LLDB没有直接对应info functions的命令，但可以通过以下方式查看所有函数符号：

• 先确认当前加载的二进制镜像：image list -f
• 导出指定镜像的完整符号表（替换<镜像序号或路径>为你的主二进制文件）：image dump symtab <镜像序号或路径>
• 过滤仅显示函数符号：image dump symtab <镜像序号或路径> | grep -E 'type=Function'
• 快速定位特定函数：image lookup -n <函数名>，比如image lookup -n start能列出所有名为start的符号位置

断点显示“22 locations”的原因 #

breakpoint set --name start会匹配**所有加载的二进制（主程序+依赖动态库）**中名为start的符号，出现22个位置通常是这些情况：

• 你的Mach-O是多架构fat二进制（比如同时支持x86_64和arm64），每个架构的二进制里都存在start符号
• 依赖的系统动态库或第三方库中包含同名的start符号（部分动态库初始化流程会使用同名入口）
• 符号表中存在重复的弱符号、静态链接库引入的同名符号

断点未触发的可能原因 #

1. 断点命中了其他模块的start：大部分断点位置在依赖库而非主程序入口，主程序的start断点未生效。可以指定仅在主程序中设置断点：

   breakpoint set --name start --image <你的二进制文件名>
   

2. 二进制符号被剥离：如果是release编译的二进制，符号表可能被移除，LLDB无法识别start符号。可以执行image lookup -n start验证，若返回no symbol found则说明符号已丢失。
3. 程序入口非标准start：部分Mach-O程序会通过动态加载器直接跳转到自定义入口，而非标准start符号。可以先在main函数设断点验证：breakpoint set --name main，或通过以下命令查看二进制真实入口地址后按地址设断点：

   otool -l <二进制> | grep -A 3 -B 3 entry
   breakpoint set --address <获取到的入口地址>
   

内容的提问来源于stack exchange，提问作者IRP_HANDLER