[trace][intel pt] Introduce wall clock time for each trace item

- Decouple TSCs from trace items
- Turn TSCs into events just like CPUs. The new name is HW clock tick, wich could be reused by other

[trace][intel pt] Introduce wall clock time for each trace item

- Decouple TSCs from trace items
- Turn TSCs into events just like CPUs. The new name is HW clock tick, wich could be reused by other vendors.
- Add a GetWallTime that returns the wall time that the trace plug-in can infer for each trace item.
- For intel pt, we are doing the following interpolation: if an instruction takes less than 1 TSC, we use that duration, otherwise, we assume the instruction took 1 TSC. This helps us avoid having to handle context switches, changes to kernel, idle times, decoding errors, etc. We are just trying to show some approximation and not the real data. For the real data, TSCs are the way to go. Besides that, we are making sure that no two trace items will give the same interpolation value. Finally, we are using as time 0 the time at which tracing started.

Sample output:

```
(lldb) r
Process 750047 launched: '/home/wallace/a.out' (x86_64)
Process 750047 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
frame #0: 0x0000000000402479 a.out`main at main.cpp:29:20
26 };
27
28 int main() {
-> 29 std::vector<int> vvv;
30 for (int i = 0; i < 100; i++)
31 vvv.push_back(i);
32
(lldb) process trace start -s 64kb -t --per-cpu
(lldb) b 60
Breakpoint 2: where = a.out`main + 1689 at main.cpp:60:23, address = 0x0000000000402afe
(lldb) c
Process 750047 resuming
Process 750047 stopped
* thread #1, name = 'a.out', stop reason = breakpoint 2.1
frame #0: 0x0000000000402afe a.out`main at main.cpp:60:23
57 map<int, int> m;
58 m[3] = 4;
59
-> 60 map<string, string> m2;
61 m2["5"] = "6";
62
63 std::vector<std::string> vs = {"2", "3"};
(lldb) thread trace dump instructions -t -f -e thread #1: tid = 750047
0: [379567.000 ns] (event) HW clock tick [48599428476224707]
1: [379569.000 ns] (event) CPU core changed [new CPU=2]
2: [390487.000 ns] (event) HW clock tick [48599428476246495]
3: [1602508.000 ns] (event) HW clock tick [48599428478664855]
4: [1662745.000 ns] (event) HW clock tick [48599428478785046]
libc.so.6`malloc
5: [1662746.995 ns] 0x00007ffff7176660 endbr64
6: [1662748.991 ns] 0x00007ffff7176664 movq 0x32387d(%rip), %rax ; + 408
7: [1662750.986 ns] 0x00007ffff717666b pushq %r12
8: [1662752.981 ns] 0x00007ffff717666d pushq %rbp
9: [1662754.977 ns] 0x00007ffff717666e pushq %rbx
10: [1662756.972 ns] 0x00007ffff717666f movq (%rax), %rax
11: [1662758.967 ns] 0x00007ffff7176672 testq %rax, %rax
12: [1662760.963 ns] 0x00007ffff7176675 jne 0x9c7e0 ; <+384>
13: [1662762.958 ns] 0x00007ffff717667b leaq 0x17(%rdi), %rax
14: [1662764.953 ns] 0x00007ffff717667f cmpq $0x1f, %rax
15: [1662766.949 ns] 0x00007ffff7176683 ja 0x9c730 ; <+208>
16: [1662768.944 ns] 0x00007ffff7176730 andq $-0x10, %rax
17: [1662770.939 ns] 0x00007ffff7176734 cmpq $-0x41, %rax
18: [1662772.935 ns] 0x00007ffff7176738 seta %dl
19: [1662774.930 ns] 0x00007ffff717673b jmp 0x9c690 ; <+48>
20: [1662776.925 ns] 0x00007ffff7176690 cmpq %rdi, %rax
21: [1662778.921 ns] 0x00007ffff7176693 jb 0x9c7b0 ; <+336>
22: [1662780.916 ns] 0x00007ffff7176699 testb %dl, %dl
23: [1662782.911 ns] 0x00007ffff717669b jne 0x9c7b0 ; <+336>
24: [1662784.906 ns] 0x00007ffff71766a1 movq 0x3236c0(%rip), %r12 ; + 24
(lldb) thread trace dump instructions -t -f -e -J -c 4
[
{
"id": 0,
"timestamp_ns": "379567.000000",
"event": "HW clock tick",
"hwClock": 48599428476224707
},
{
"id": 1,
"timestamp_ns": "379569.000000",
"event": "CPU core changed",
"cpuId": 2
},
{
"id": 2,
"timestamp_ns": "390487.000000",
"event": "HW clock tick",
"hwClock": 48599428476246495
},
{
"id": 3,
"timestamp_ns": "1602508.000000",
"event": "HW clock tick",
"hwClock": 48599428478664855
},
{
"id": 4,
"timestamp_ns": "1662745.000000",
"event": "HW clock tick",
"hwClock": 48599428478785046
},
{
"id": 5,
"timestamp_ns": "1662746.995324",
"loadAddress": "0x7ffff7176660",
"module": "libc.so.6",
"symbol": "malloc",
"mnemonic": "endbr64"
},
{
"id": 6,
"timestamp_ns": "1662748.990648",
"loadAddress": "0x7ffff7176664",
"module": "libc.so.6",
"symbol": "malloc",
"mnemonic": "movq"
},
{
"id": 7,
"timestamp_ns": "1662750.985972",
"loadAddress": "0x7ffff717666b",
"module": "libc.so.6",
"symbol": "malloc",
"mnemonic": "pushq"
},
{
"id": 8,
"timestamp_ns": "1662752.981296",
"loadAddress": "0x7ffff717666d",
"module": "libc.so.6",
"symbol": "malloc",
"mnemonic": "pushq"
}
]
```

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

show more ...

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com:

1094796 1095721 1095728 1095737 1095741
1095756 1095779 1095789 1095805 1214552
1229457 1232475 1274006 1274010 1293427
1364800 1364802 1364804 1364812 1364816
1374902 1374909 1384975 1399312 1420451
1431704 1454230 1454554 1454615 1454579
1454594 1454832 1457759 1458696 1461909
1467658 1487814 1487830 1487845

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

show more ...

[lldb] Refactor command option enum values (NFC)

Refactor the command option enum values and the command argument table
to connect the two. This has two benefits:

- We guarantee that two options t

[lldb] Refactor command option enum values (NFC)

Refactor the command option enum values and the command argument table
to connect the two. This has two benefits:

- We guarantee that two options that use the same argument type have
the same accepted values.
- We can print the enum values and their description in the help
output. (D129707)

Differential revision: https://reviews.llvm.org/D129703

show more ...

[trace][intel pt] Support dumping the trace info in json

Thanks to [email protected] for coming up with this change.

`thread trace dump info` can dump some metrics that can be useful for
analyzing the p

[trace][intel pt] Support dumping the trace info in json

Thanks to [email protected] for coming up with this change.

`thread trace dump info` can dump some metrics that can be useful for
analyzing the performance and quality of a trace. This diff adds a --json
option for dumping this information in json format that can be easily
understood my machines.

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

show more ...

[trace] Add a flag to the decoder to output the instruction type

To build complex binding upon instruction trace, additional metadata 'instruction type' is needed.

This diff has followings:
- Add

[trace] Add a flag to the decoder to output the instruction type

To build complex binding upon instruction trace, additional metadata 'instruction type' is needed.

This diff has followings:
- Add a flag -k / --kind for instruction dump
- Remove SetGranularity and SetIgnoreErros from Trace cursor

Sample output:

```
(lldb) thread trace dump instruction -k
thread #1: tid = 3198805
libc.so.6`_IO_puts + 356
2107: 0x00007ffff7163594 ( return) retq
2106: 0x00007ffff7163592 ( other) popq %r13
2105: 0x00007ffff7163590 ( other) popq %r12
2104: 0x00007ffff716358f ( other) popq %rbp
2103: 0x00007ffff716358e ( other) popq %rbx
2102: 0x00007ffff716358c ( other) movl %ebx, %eax
2101: 0x00007ffff7163588 ( other) addq $0x8, %rsp
2100: 0x00007ffff7163570 ( cond jump) je 0x89588 ; <+344>
2099: 0x00007ffff716356e ( other) decl (%rdx)
2098: 0x00007ffff7163565 ( cond jump) je 0x8956e ; <+318>
2097: 0x00007ffff716355e ( other) cmpl $0x0, 0x33c02b(%rip) ; __libc_multiple_threads
2096: 0x00007ffff7163556 ( other) movq $0x0, 0x8(%rdx)
2095: 0x00007ffff7163554 ( cond jump) jne 0x89588 ; <+344>
2094: 0x00007ffff7163550 ( other) subl $0x1, 0x4(%rdx)
2093: 0x00007ffff7163549 ( other) movq 0x88(%rbp), %rdx
2092: 0x00007ffff7163547 ( cond jump) jne 0x89588 ; <+344>
2091: 0x00007ffff7163540 ( other) testl $0x8000, (%rbp) ; imm = 0x8000
2090: 0x00007ffff716353c ( other) cmovaq %rax, %rbx
2089: 0x00007ffff7163535 ( other) cmpq $0x7fffffff, %rbx ; imm = 0x7FFFFFFF
2088: 0x00007ffff7163530 ( other) movl $0x7fffffff, %eax ; imm = 0x7FFFFFFF
```

Reviewed By: wallace

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

show more ...

[lldb] Fix thread step until to not set breakpoint(s) on incorrect line numbers

The requirements for "thread until <line number>" are:

a) If any code contributed by <line number> or the nearest sub

[lldb] Fix thread step until to not set breakpoint(s) on incorrect line numbers

The requirements for "thread until <line number>" are:

a) If any code contributed by <line number> or the nearest subsequent of <line number> is executed before leaving the function, stop
b) If you end up leaving the function w/o triggering (a), then stop

In case of (a), since the <line number> may have multiple entries in the line table and the compiler might have scheduled/moved the relevant code across, and the lldb does not know the control flow, set breakpoints on all the line table entries of best match of <line number> i.e. exact or the nearest subsequent line.

Along with the above, currently, CommandObjectThreadUntil is also setting the breakpoints on all the subsequent line numbers after the best match and this latter part is wrong.

This issue is discussed at http://lists.llvm.org/pipermail/lldb-dev/2018-August/013979.html.

In fact, currently `TestStepUntil.py` is not actually testing step until scenarios and `test_missing_one` test fails without this patch if tests are made to run. Fixed the test as well.

Reviewed By: jingham

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

show more ...

[trace] Make events first class items in the trace cursor and rework errors

We want to include events with metadata, like context switches, and this
requires the API to handle events with payloads (

[trace] Make events first class items in the trace cursor and rework errors

We want to include events with metadata, like context switches, and this
requires the API to handle events with payloads (e.g. information about
such context switches). Besides this, we want to support multiple
similar events between two consecutive instructions, like multiple
context switches. However, the current implementation is not good for this because
we are defining events as bitmask enums associated with specific
instructions. Thus, we need to decouple instructions from events and
make events actual items in the trace, just like instructions and
errors.

- Add accessors in the TraceCursor to know if an item is an event or not
- Modify from the TraceDumper all the way to DecodedThread to support
- Renamed the paused event to disabled.
- Improved the tsc handling logic. I was using an API for getting the tsc from libipt, but that was an overkill that should be used when not processing events manually, but as we are already processing events, we can more easily get the tscs.
event items. Fortunately this simplified many things
- As part of this refactor, I also fixed and long stating issue, which is that some non decoding errors were being inserted in the decoded thread. I changed this so that TraceIntelPT::Decode returns an error if the decoder couldn't be set up proplerly. Then, errors within a trace are actual anomalies found in between instrutions.

All test pass

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

show more ...

[trace] Fix errors when handling command arguments

https://reviews.llvm.org/D128453 recently added some safety checks for
command arguments. Unfortunately, some few commands started failing due
to t

[trace] Fix errors when handling command arguments

https://reviews.llvm.org/D128453 recently added some safety checks for
command arguments. Unfortunately, some few commands started failing due
to that, and this diff fixes it. But fortunately, the fix is trivial, which is
simply declaring the argument that these commands will receive.

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

show more ...

[trace] Improve the TraceCursor iteration API

The current way ot traversing the cursor is a bit uncommon and it can't handle empty traces, in fact, its invariant is that it shold always point to a v

[trace] Improve the TraceCursor iteration API

The current way ot traversing the cursor is a bit uncommon and it can't handle empty traces, in fact, its invariant is that it shold always point to a valid item. This diff simplifies the cursor API and allows it to point to invalid items, thus being able to handle empty traces or to know it ran out of data.

- Removed all the granularity functionalities, because we are not actually making use of that. We can bring them back when they are actually needed.
- change the looping logic to the following:

```
for (; cursor->HasValue(); cursor->Next()) {
if (cursor->IsError()) {
.. do something for error
continue;
}
.. do something for instruction
}

```

- added a HasValue method that can be used to identify if the cursor ran out of data, the trace is empty, or the user tried to move to an invalid position via SetId() or Seek()
- made several simplifications to severals parts of the code.

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

show more ...

Revert "[lldb] Fix thread step until to not set breakpoint(s) on incorrect line numbers"

This reverts commit a57b62deef37c7f2ec31bca3bf9173a6206bfb9b.

lldb-aarch64-ubuntu buildbot test fails since

Revert "[lldb] Fix thread step until to not set breakpoint(s) on incorrect line numbers"

This reverts commit a57b62deef37c7f2ec31bca3bf9173a6206bfb9b.

lldb-aarch64-ubuntu buildbot test fails since https://lab.llvm.org/buildbot/#/builders/96/builds/25128

show more ...

[lldb] Fix thread step until to not set breakpoint(s) on incorrect line numbers

The requirements for "thread until <line number>" are:

a) If any code contributed by <line number> or the nearest sub

[lldb] Fix thread step until to not set breakpoint(s) on incorrect line numbers

The requirements for "thread until <line number>" are:

a) If any code contributed by <line number> or the nearest subsequent of <line number> is executed before leaving the function, stop
b) If you end up leaving the function w/o triggering (a), then stop

In case of (a), since the <line number> may have multiple entries in the line table and the compiler might have scheduled/moved the relevant code across, and the lldb does not know the control flow, set breakpoints on all the line table entries of best match of <line number> i.e. exact or the nearest subsequent line.

Along with the above, currently, CommandObjectThreadUntil is also setting the breakpoints on all the subsequent line numbers after the best match and this latter part is wrong.

This issue is discussed at http://lists.llvm.org/pipermail/lldb-dev/2018-August/013979.html.

In fact, currently `TestStepUntil.py` is not actually testing step until scenarios and `test_missing_one` test fails without this patch if tests are made to run. Fixed the test as well.

Reviewed By: jingham

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

show more ...

[trace] Add an option to dump instructions in json and to a file

In order to provide simple scripting support on top of instruction traces, a simple solution is to enhance the `dump instructions` co

[trace] Add an option to dump instructions in json and to a file

In order to provide simple scripting support on top of instruction traces, a simple solution is to enhance the `dump instructions` command and allow printing in json and directly to a file. The format is verbose and not space efficient, but it's not supposed to be used for really large traces, in which case the TraceCursor API is the way to go.

- add a -j option for printing the dump in json
- add a -J option for pretty printing the json output
- add a -F option for specifying an output file
- add a -a option for dumping all the instructions available starting at the initial point configured with the other flags
- add tests for all cases
- refactored the instruction dumper and abstracted the actual "printing" logic. There are two writer implementations: CLI and JSON. This made the dumper itself much more readable and maintanable

sample output:

```
(lldb) thread trace dump instructions -t -a --id 100 -J
[
{
"id": 100,
"tsc": "43591204528448966"
"loadAddress": "0x407a91",
"module": "a.out",
"symbol": "void std::deque<Foo, std::allocator<Foo>>::_M_push_back_aux<Foo>(Foo&&)",
"mnemonic": "movq",
"source": "/usr/include/c++/8/bits/deque.tcc",
"line": 492,
"column": 30
},
...
```

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

show more ...

[LLDB] CommandObjectThreadUntil::DoExecute() sets the wrong selected thread ID

For the 'thread until' command, the selected thread ID, to perform the operation on, could be of the current thread or

[LLDB] CommandObjectThreadUntil::DoExecute() sets the wrong selected thread ID

For the 'thread until' command, the selected thread ID, to perform the operation on, could be of the current thread or the specified thread.

Reviewed By: jingham

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

show more ...

[trace][intel pt] Support events

A trace might contain events traced during the target's execution. For
example, a thread might be paused for some period of time due to context
switches or breakpoin

[trace][intel pt] Support events

A trace might contain events traced during the target's execution. For
example, a thread might be paused for some period of time due to context
switches or breakpoints, which actually force a context switch. Not only
that, a trace might be paused because the CPU decides to trace only a
specific part of the target, like the address filtering provided by
intel pt, which will cause pause events. Besides this case, other kinds
of events might exist.

This patch adds the method `TraceCursor::GetEvents()`` that returns the
list of events that happened right before the instruction being pointed
at by the cursor. Some refactors were done to make this change simpler.

Besides this new API, the instruction dumper now supports the -e flag
which shows pause events, like in the following example, where pauses
happened due to breakpoints.

```
thread #1: tid = 2717361
a.out`main + 20 at main.cpp:27:20
0: 0x00000000004023d9 leaq -0x1200(%rbp), %rax
[paused]
1: 0x00000000004023e0 movq %rax, %rdi
[paused]
2: 0x00000000004023e3 callq 0x403a62 ; std::vector<int, std::allocator<int> >::vector at stl_vector.h:391:7
a.out`std::vector<int, std::allocator<int> >::vector() at stl_vector.h:391:7
3: 0x0000000000403a62 pushq %rbp
4: 0x0000000000403a63 movq %rsp, %rbp
```

The `dump info` command has also been updated and now it shows the
number of instructions that have associated events.

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

show more ...

[trace][intelpt] Introduce instruction Ids

In order to support quick arbitrary access to instructions in the trace, we need
each instruction to have an id. It could be an index or any other value th

[trace][intelpt] Introduce instruction Ids

In order to support quick arbitrary access to instructions in the trace, we need
each instruction to have an id. It could be an index or any other value that the
trace plugin defines.

This will be useful for reverse debugging or for creating callstacks, as each
frame will need an instruction id associated with them.

I've updated the `thread trace dump instructions` command accordingly. It now
prints the instruction id instead of relative offset. I've also added a new --id
argument that allows starting the dump from an arbitrary position.

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

show more ...

[simple] fix some the documentation

Some links were not rendered correctly in the intel pt documentation and
some spacing was fixed in some command objects.

[trace][intelpt] fix some test failures

Minor fixes needed and now `./bin/lldb-dotest -p TestTrace` passes
correctly.

- There was an incorrect iteration.
- Some error messages changed.
- The way re

[trace][intelpt] fix some test failures

Minor fixes needed and now `./bin/lldb-dotest -p TestTrace` passes
correctly.

- There was an incorrect iteration.
- Some error messages changed.
- The way repeat commands are handled changed a bit, so I had to create
a new --continue arg in "thread trace dump instructions" to handle this
correctly.

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

show more ...

[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB

Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in cl

[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB

Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in class member init but
never updated the constructors to reflect that. This check is already present in
the lldb/.clang-tidy config.

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

show more ...

Fix an incorrect assumption in "thread until": code with debug info is not always in a function.

Some dyld cross library stubs can have line information but no function. Make sure you
check that yo

Fix an incorrect assumption in "thread until": code with debug info is not always in a function.

Some dyld cross library stubs can have line information but no function. Make sure you
check that you have a valid Function object before asking it questions.

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

show more ...

Add a repeat command option for "thread backtrace --count N".

This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the

Add a repeat command option for "thread backtrace --count N".

This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the stack.

This took a little more effort than just adding the repeat command, since
the GetRepeatCommand API was returning a "const char *". That meant the command
had to keep the repeat string alive, which is inconvenient. The original
API returned either a nullptr, or a const char *, so I changed the private API to
return an llvm::Optional<std::string>. Most of the patch is propagating that change.

Also, there was a little thinko in fetching the repeat command. We don't
fetch repeat commands for commands that aren't being added to history, which
is in general reasonable. And we don't add repeat commands to the history -
also reasonable. But we do want the repeat command to be able to generate
the NEXT repeat command. So I adjusted the logic in HandleCommand to work
that way.

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

show more ...

[lldb] [Commands] Implement "thread siginfo"

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

[Commands] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

[lldb][NFC] Inclusive Language: rename master plan to controlling plan

[NFC] As part of using inclusive language within the llvm project, this patch
renames master plan to controlling plan in lldb.

[lldb][NFC] Inclusive Language: rename master plan to controlling plan

[NFC] As part of using inclusive language within the llvm project, this patch
renames master plan to controlling plan in lldb.

Reviewed By: jingham

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

show more ...

[lldb] Remove ConstString from SymbolVendor, Trace, TraceExporter, UnwindAssembly, MemoryHistory and InstrumentationRuntime plugin names

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.

I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.

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

show more ...