Scrutinize and Document the bahavior of stepping into/over on ILs

[xusheng6]

Right now, we support stepping into/over on the ILs. However, its behavior is not clearly documented. In fact, suppose we have some disassembly code like this:

1400012d1  488d15200f0000     lea     rdx, [rel data_1400021f8]
1400012d8  488d0d010f0000     lea     rcx, [rel data_1400021e0]
1400012df  e89e0a0000         call    _initterm_e

and the corresponding HLIL is:

1400012df              rax_2 = _initterm_e(&data_1400021e0, &data_1400021f8)

So, if we step in HLIL, when it breaks at 0x1400012df, where should the underlying program counter be?

Right now, with the implementation inherited from the previous Python debugger, it breaks when the rip is 0x1400012df. However, the HLIL instruction is already partially executed by that time, so the behavior might be confusing in certain cases.

I checked other source-level debuggers, e.g., gdb, VS, and it seems that breaking on the first instruction the common practice.

It is not immediately clear how easy/hard to switch to the other way of handling it. Also, it causes a UI problem because if we break at 1400012d1, the UI will try to navigate to 1400012d1, which has no corresponding HLIL instruction. The situation can be messy, in the best case it will navigate to the HLIL instruction before the current one, effectively causing an off-by-one visual error. Or, it could navigate to somewhere unrelated, causing big confusion.

That said, the navigation problem might be solved by taking the current IL into consideration.

We should either adopt the common way of handling the stepping, or document the way we do it.

[xusheng6]

After a discussion with the team, we believe the current behavior of breaking at the disassembly instruction that has the same address as the IL instruction is a reasonable behavior. We need to document the behavior.