[Lldb-commits] [PATCH] D91238: Recognize __builtin_debugtrap on arm64, advance pc past it so users can continue easily
Greg Clayton via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Wed Nov 11 14:33:45 PST 2020
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.
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
More information about the lldb-commits