jingham added a comment.
Just to be clear, the lldb -> gdb command map doesn't prescribe behavior for
lldb commands. It just suggests the analogous command in gdb. We are still
free to implement lldb behavior however seems best to us.
The logic in lldb doesn't change the logic of the program's execution. This is
just about when we return control to the user.
I can't 100% remember why I checked that the pc changed originally - it has
been this way forever... But I think I was worried that you would do a stepi
and another thread would make progress but this thread wouldn't and then we'd
call the stepi completed. That would be confusing, since you would look to see
the effects of the instruction we told you got to run, and they wouldn't be
there...
However, the code that queries for stop reasons is pretty careful to avoid
asking questions of threads that didn't stop "for a reason". So, what actually
happens nowadays is that we would note that we hadn't gotten the "trace" stop
state for this thread, not consult the thread's plan stack at all, and so we
wouldn't end up misreporting the stop reason. So I don't think that's a real
concern.
On the grounds that it is always better, when in doubt, to return control to
the user & let them figure out what to do that to keep going on, I'm fine with
the changed behavior.
If you want to keep this behavior from changing over time, however, you
probably want to write a test for it. I don't think you can count on `while
{}` always having a jump back to itself. But you could write an inline asm
test that inserts this instruction and make sure that stops after the stepi.
That would be architecture specific, but I don't see another way to get this
behavior in a way that you can test for it.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D81810/new/
https://reviews.llvm.org/D81810
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
