[all-commits] [llvm/llvm-project] ade59d: [trace] Dedup different source lines when dumping ...

[walter erquinigo via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: ade59d530964e28498051ab20e44cbf6594be595
      https://github.com/llvm/llvm-project/commit/ade59d530964e28498051ab20e44cbf6594be595
  Author: Walter Erquinigo <a20012251 at gmail.com>
  Date:   2021-05-04 (Tue, 04 May 2021)

  Changed paths:
    M lldb/include/lldb/Core/AddressRange.h
    M lldb/include/lldb/Target/Trace.h
    M lldb/source/Core/AddressRange.cpp
    M lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.cpp
    M lldb/source/Plugins/Trace/intel-pt/TraceIntelPT.h
    M lldb/source/Target/Trace.cpp
    M lldb/test/API/commands/trace/TestTraceStartStop.py

  Log Message:
  -----------
  [trace] Dedup different source lines when dumping instructions + refactor

When dumping the traced instructions in a for loop, like this one

  4:  for (int a = 0; a < n; a++)
  5:    do something;

there might be multiple LineEntry objects for line 4, but with different address ranges. This was causing the dump command to dump something like this:

```
  a.out`main + 11 at main.cpp:4
    [1] 0x0000000000400518    movl   $0x0, -0x8(%rbp)
    [2] 0x000000000040051f    jmp    0x400529                  ; <+28> at main.cpp:4
  a.out`main + 28 at main.cpp:4
    [3] 0x0000000000400529    cmpl   $0x3, -0x8(%rbp)
    [4] 0x000000000040052d    jle    0x400521                  ; <+20> at main.cpp:5
```

which is confusing, as main.cpp:4 appears twice consecutively.

This diff fixes that issue by making the line entry comparison strictly about the line, column and file name. Before it was also comparing the address ranges, which we don't need because our output is strictly about what the user sees in the source.

Besides, I've noticed that the logic that traverses instructions and calculates symbols and disassemblies had too much coupling, and made my changes harder to implement, so I decided to decouple it. Now there are two methods for iterating over the instruction of a trace. The existing one does it on raw load addresses, but the one provides a SymbolContext and an InstructionSP, and does the calculations efficiently (not as efficient as possible for now though), so the caller doesn't need to care about these details. I think I'll be using that iterator to reconstruct the call stacks.

I was able to fix a test with this change.

Differential Revision: https://reviews.llvm.org/D100740