jasonmolenda wrote: > > I also needed to remove the brk #0xf000 instruction because lldb is not > > able to step over it -- it just ends up spinning forever. FWICS, it's not > > actually necessary now that you're stepping through the test. Nonetheless, > > this is a bug -- one that @DavidSpickett might be interested in :) > > Yes I've been asked a few times about it. GDB also has problems with it, but > probably does something slightly more useful. I'll speak to folks on that > side and see how we could handle this.
@DavidSpickett sorry I missed this discussion a few weeks ago. Yeah, in debugserver aarch64 backend we check for the current instruction being `brk #0xf000` specifically and move $pc to the next instruction. Customers were using `__builtin_debugtrap()` in their code to force a break in the debugger, and wanted to continue stepping after hitting that, like they could on Intel systems (where the pc was past the interrupt instruction). I wasn't sure if it was best to special case this in debugserver, or up in lldb in some architecture dependent stepping plan when we're stopped at this instruction, I may have chosen poorly. https://github.com/llvm/llvm-project/pull/138805 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
