[Lldb-commits] [PATCH] D17535: [LLDB][MIPS] Single step atomic sequences

[Tamas Berghammer via lldb-commits]

tberghammer added a comment.

I am not sure I agree with the following starting point of the CL (I know about the similar functionality in GDB) and even if we agree in it I think you are handling a very small fraction of the problems.

> LLDB should treat all instructions in the atomic sequence as if they are a single instruction i.e as a "single instruction block".


I think there are 3 scenario around atomic sequences:

1. You are setting a breakpoint what fails inside of the atomic sequence
2. You are line level stepping over an atomic sequence
3. You are instruction level single stepping over an atomic sequence

For me the expected behavior in scenario 1 and 2 is to set the breakpoint at the address specified and handle the atomic sequence when you try to continue from the breakpoint (I hope that the compilers are generally not putting line breaks / symbols in the middle of an atomic sequence). I think the 3. scenario will happen when you are doing assembly level debugging of an atomic sequence where I would expect to step only 1 instruction as I am debugging assembly code.

If I understand your CL correctly then you only handle the scenario when we are single stepping from an LL instruction. This definitely not solving the issue when an we setting a breakpoint in the middle of an atomic sequence and then try to continue from there while it is preventing the user from doing an instruction level debugging of the atomic sequences.

I would be more happy with the following functionalities (not necessarily implementing all edge case for the first iteration):

- Step instruction behaves as it did before (1 instruction, ignores the atomic sequence)
- If we continue from a breakpoint placed inside an atomic sequence then we put back the breakpoint only after we left the atomic sequence

Please let me know what do you think.

P.S.: Have you hit any issue regarding atomic sequences during regular debugging? I would be interested about a usecase when they are affecting the debug experience so we can target the problematic point.


Repository:
  rL LLVM

http://reviews.llvm.org/D17535