clayborg added a comment. In D91238#2389877 <https://reviews.llvm.org/D91238#2389877>, @jasonmolenda wrote:
> Yeah, I don't know where it's best to centralize the logic of (1) recognize a > builtin_debugtrap instruction, and (2) set the pc so we step past it, know > how to step past it when the user asks to resume control. debugserver (and > lldb-server I'm sure) are already lying a *little* with a normal x86 user > breakpoint - when you execute 0xcc at addr 0x100, the stop pc is 0x101 and > someone is rolling that back to 0x100 to report the breakpoint hit > (debugserver does this, I'm sure lldb-server does the same). So we're just > adding more lies into the remote stub. > > You could argue that the stub should always set $pc to be the instruction > that hit the breakpoint/undefined instruction (so on x86, back up the pc by > 1) and lldb should look at the breakpoint list / instruction bytes and decide > if this was a user breakpoint or a builtin_trap of some kind. And when it's > a builtin_debugtrap, and the user continues/steps/nexts, lldb could advance > $pc past the instruction and then do the nexting. > > I don't have much of an opinion about where this knowledge and pc adjusting > should happen. Jim might though. No worries, this solution is simple and will work just fine. I have no issues either way. It will be interesting to see what Jim suggests. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91238/new/ https://reviews.llvm.org/D91238 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
