我尝试了“ breakpoint [行号]”，“ breakpoint filename.s：line_number”，但是它们不起作用。目前，我必须完成所有步骤，这很麻烦
答案 0 :(得分：2)
作为替代，您可以：
1）显示带有汇编指令的内存
di
带有显式参数
如果您需要进一步联系
di -c 1000 ;
如果您需要拆卸特定地址
di -s <address>
2）设置内存断点
br s -a <memory address you found in previous step>
另一种选择更具破坏性，但实际上更省力，这在您的情况下可能有用也可能没有用。您可以在汇编代码中进行无效的syscall。您的程序将愉快地继续执行，但是在lldb / SIGSYS进行系统调用之后，EXC_SYSCALL将在下一条指令上中断。您尚未指定目标是x86-64还是arm，因此设置会略有不同。
对于 x86-64 ，您将拥有
syscall
假设您的rax寄存器不是有效的系统调用，即在0x2000xxx范围内，破坏性部分将包括：
1）将rax寄存器的高32位清零
2）r11将成为rflags
3）rcx将变成rip（XNU内核使用它来从syscall返回用户空间），但是正如我here
rcx将变为rsp
对于 32位和 64位臂，您可以使用以下方式进行系统调用：
svc 0x80
任何1个字节^数字都可以使用，但是按照惯例，它是0x80。
32位使用r12作为系统调用号码。 64位使用x16。更多信息here和here。因此，基本上有效的范围是0x0-0x0xxx。甚至无效的系统调用似乎也会影响x0和x1（对于64位，因为我没有要测试的32位设备）。因此，只要您考虑到x0和x1在系统调用后受到影响，并且碰巧有x16是无效的系统调用，那么您就可以使用了。
更新 对于@PeterCordes的出色发言， x86的另一种替代方法是：
int3
即调试器陷阱
等效臂是
trap
与syscall的区别与int3 / trap之后的程序执行将且仅在调试器为附加和lldb continue命令，其附加值是完全不影响寄存器。在syscall方法中，程序也将继续执行，而调试器不会附加上述寄存器。