[Lldb-commits] [PATCH] D81810: LLDB step-instruction gets stuck on jump to self

[Jim Ingham via Phabricator via lldb-commits]

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