That shouldn't be too hard to do. We already have machinery to inject a "step
over breakpoint trap" ThreadPlan when we continue, so we could use the same
detection point to just move the PC before continuing in the case of an
unrecognized trap.
Jim
> On Mar 5, 2020, at 10:10 AM, Jim Ingham v
BTW, I think the better way to handle this in lldb is not to move the PC past
the trap when you stop, but that when CONTINUING past a trap that we don't
recognize, we always make sure we start past the trap. That way it won't look
weird when people compare crash logs coming from hitting a trap
On 04/03/2020 21:45, Jim Ingham via llvm-dev wrote:
> As you have seen, different machine architectures do different things after
> hitting a trap. On x86_64, the trap instruction is executed, and then you
> stop, so the PC is left after the stop. On arm64, when execution halts the
> pc is sti
