|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
| #
3c849d0a |
| 15-Jul-2022 |
Fangrui Song <[email protected]> |
Modernize Optional::{getValueOr,hasValue}
|
| #
d30fd5c3 |
| 29-Jun-2022 |
Gaurav Gaur <[email protected]> |
[trace][intel pt] Add a cgroup filter
It turns out that cgroup filtering is relatively trivial and works really nicely. Thid diffs adds automatic cgroup filtering when in per-cpu mode, unless a new
[trace][intel pt] Add a cgroup filter
It turns out that cgroup filtering is relatively trivial and works really nicely. Thid diffs adds automatic cgroup filtering when in per-cpu mode, unless a new --disable-cgroup-filtering flag is passed in the start command. At least on Meta machines, all processes are spawned inside a cgroup by default, which comes super handy, because per cpu tracing is now much more precise.
A manual test gave me this result
- Without filtering: Total number of trace items: 36083 Total number of continuous executions found: 229 Number of continuous executions for this thread: 2 Total number of PSB blocks found: 98 Number of PSB blocks for this thread 2 Total number of unattributed PSB blocks found: 38
- With filtering: Total number of trace items: 87756 Total number of continuous executions found: 123 Number of continuous executions for this thread: 2 Total number of PSB blocks found: 10 Number of PSB blocks for this thread 3 Total number of unattributed PSB blocks found: 2
Filtering gives us great results. The number of instructions collected more than double (probalby because we have less noise in the trace), and we have much less unattributed PSBs blocks and unrelated PSBs in general. The ones that are unrelated probably belong to other processes in the same cgroup.
Differential Revision: https://reviews.llvm.org/D129257
show more ...
|
| #
e095cddb |
| 28-Jun-2022 |
Michał Górny <[email protected]> |
[lldb] Add a NativeProcessProtocol::Threads() iterable
Sponsored by: The FreeBSD Foundation Differential Revision: https://reviews.llvm.org/D128698
|
|
Revision tags: llvmorg-14.0.6 |
|
| #
6a5355e8 |
| 14-Jun-2022 |
Walter Erquinigo <[email protected]> |
[trace][intelpt] Support system-wide tracing [20] - Rename some fields in the schema
As discusses offline with @jj10305, we are updating some naming used throughout the code, specially in the json s
[trace][intelpt] Support system-wide tracing [20] - Rename some fields in the schema
As discusses offline with @jj10305, we are updating some naming used throughout the code, specially in the json schema
- traceBuffer -> iptTrace - core -> cpu
Differential Revision: https://reviews.llvm.org/D127817
show more ...
|
|
Revision tags: llvmorg-14.0.5 |
|
| #
03cc58ff |
| 08-Jun-2022 |
Walter Erquinigo <[email protected]> |
[trace][intelpt] Support system-wide tracing [17] - Some improvements
This improves several things and addresses comments up to the diff [11] in this stack.
- Simplify many functions to receive les
[trace][intelpt] Support system-wide tracing [17] - Some improvements
This improves several things and addresses comments up to the diff [11] in this stack.
- Simplify many functions to receive less parameters that they can identify easily - Create Storage classes for Trace and TraceIntelPT that can make it easier to reason about what can change with live process refreshes and what cannot. - Don't cache the perf zero conversion numbers in lldb-server to make sure we get the most up-to-date numbers. - Move the thread identifaction from context switches to the bundle parser, to leave TraceIntelPT simpler. This also makes sure that the constructor of TraceIntelPT is invoked when the entire data has been checked to be correct. - Normalize all bundle paths before the Processes, Threads and Modules are created, so that they can assume that all paths are correct and absolute - Fix some issues in the tests. Now they all pass. - return the specific instance when constructing PerThread and MultiCore processor tracers. - Properly implement IntelPTMultiCoreTrace::TraceStart. - Improve some comments. - Use the typedef ContextSwitchTrace more often for clarity. - Move CreateContextSwitchTracePerfEvent to Perf.h as a utility function. - Synchronize better the state of the context switch and the intel pt perf events. - Use a booblean instead of an enum for the PerfEvent state.
Differential Revision: https://reviews.llvm.org/D127456
show more ...
|
|
Revision tags: llvmorg-14.0.4 |
|
| #
fc5ef57c |
| 19-May-2022 |
Walter Erquinigo <[email protected]> |
[trace][intelpt] Support system-wide tracing [12] - Support multi-core trace load and save
:q! This diff is massive, but it's because it connects the client with lldb-server and also ensures that th
[trace][intelpt] Support system-wide tracing [12] - Support multi-core trace load and save
:q! This diff is massive, but it's because it connects the client with lldb-server and also ensures that the postmortem case works.
- Flatten the postmortem trace schema. The reason is that the schema has become quite complex due to the new multicore case, which defeats the original purpose of having a schema that could work for every trace plug-in. At this point, it's better that each trace plug-in defines it's own full schema. This means that the only common field is "type". -- Because of this new approach, I merged the "common" trace load and saving functionalities into the IntelPT one. This simplified the code quite a bit. If we eventually implement another trace plug-in, we can see then what we could reuse. -- The new schema, which is flattened, has now better comments and is parsed better. A change I did was to disallow hex addresses, because they are a bit error prone. I'm asking now to print the address in decimal. -- Renamed "intel" to "GenuineIntel" in the schema because that's what you see in /proc/cpuinfo. - Implemented reading the context switch trace data buffer. I had to do some refactors to do that cleanly. -- A major change that I did here was to simplify the perf_event circular buffer reading logic. It was too complex. Maybe the original Intel author had something different in mind. - Implemented all the necessary bits to read trace.json files with per-core data. - Implemented all the necessary bits to save to disk per-core trace session. - Added a test that ensures that parsing and saving to disk works.
Differential Revision: https://reviews.llvm.org/D126015
show more ...
|
| #
1f2d49a8 |
| 18-May-2022 |
Walter Erquinigo <[email protected]> |
[trace][intelpt] Support system-wide tracing [10] - Return warnings and tsc information from lldb-server.
- Add a warnings field in the jLLDBGetState response, for warnings to be delivered to the cl
[trace][intelpt] Support system-wide tracing [10] - Return warnings and tsc information from lldb-server.
- Add a warnings field in the jLLDBGetState response, for warnings to be delivered to the client for troubleshooting. This removes the need to silently log lldb-server's llvm::Errors and not expose them easily to the user - Simplify the tscPerfZeroConversion struct and schema. It used to extend a base abstract class, but I'm doubting that we'll ever add other conversion mechanisms because all modern kernels support perf zero. It is also the one who is supposed to work with the timestamps produced by the context switch trace, so expecting it is imperative. - Force tsc collection for cpu tracing. - Add a test checking that tscPerfZeroConversion is returned by the GetState request - Add a pre-check for cpu tracing that makes sure that perf zero values are available.
Differential Revision: https://reviews.llvm.org/D125932
show more ...
|
| #
a7582059 |
| 18-May-2022 |
Walter Erquinigo <[email protected]> |
[trace][intelpt] Support system-wide tracing [9] - Collect and return context switch traces
- Add collection of context switches per cpu grouped with the per-cpu intel pt traces. - Move the state ha
[trace][intelpt] Support system-wide tracing [9] - Collect and return context switch traces
- Add collection of context switches per cpu grouped with the per-cpu intel pt traces. - Move the state handling from the interl pt trace class to the PerfEvent one. - Add support for stopping and enabling perf event groups. - Return context switch entries as part of the jLLDBTraceGetState response. - Move the triggers of whenever the process stopped or resumed. Now the will-resume notification is in a better location, which will ensure that we'll capture the instructions that will be executed. - Remove IntelPTSingleBufferTraceUP. The unique pointer was useless. - Add unit tests
Differential Revision: https://reviews.llvm.org/D125897
show more ...
|
| #
1f56f7fc |
| 12-May-2022 |
Walter Erquinigo <[email protected]> |
[trace][intelpt] Support system-wide tracing [7] - Create a base IntelPTProcessTrace class
We have two different "process trace" implementations: per thread and per core. As a way to simplify the co
[trace][intelpt] Support system-wide tracing [7] - Create a base IntelPTProcessTrace class
We have two different "process trace" implementations: per thread and per core. As a way to simplify the collector who uses both, I'm creating a base abstract class that is used by these implementations. This effectively simplify a good chunk of code.
Differential Revision: https://reviews.llvm.org/D125503
show more ...
|
| #
8e757c6b |
| 25-May-2022 |
Thomas Preud'homme <[email protected]> |
Fix conversion error to Expected
On Ubuntu 18.04 with GCC 7.5 Intel trace code fails to build due to failure to convert from lldb_private::process_linux::IntelPTPerThreadProcessTraceUP to Expected<l
Fix conversion error to Expected
On Ubuntu 18.04 with GCC 7.5 Intel trace code fails to build due to failure to convert from lldb_private::process_linux::IntelPTPerThreadProcessTraceUP to Expected<lldb_private::process_linux::IntelPTPerThreadProcessTraceUP>. This commit explicitely marks those unique_ptr values as being moved which fixes the conversion error.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D126402
show more ...
|
| #
1188faa7 |
| 05-May-2022 |
Walter Erquinigo <[email protected]> |
[trace][intelpt] Support system-wide tracing [6] - Break IntelPTCollector into smaller files and minor refactor
IntelPTCollector is very big and has 3 classes in it. It's actually cleaner if each on
[trace][intelpt] Support system-wide tracing [6] - Break IntelPTCollector into smaller files and minor refactor
IntelPTCollector is very big and has 3 classes in it. It's actually cleaner if each one has its own file. This also gives more visibility to the developer about the different kinds of "tracers" that we have.
Besides that, I'm now restricting the creation of the BinaryData chunks to GetState() instead of having it in different places, which is not very clean, because the gdb-remote protocol should be as restricted as possible.
Differential Revision: https://reviews.llvm.org/D125047
show more ...
|
| #
1637545f |
| 04-May-2022 |
Walter Erquinigo <[email protected]> |
[trace][intelpt] Support system-wide tracing [5] - Disable/enable per-core tracing based on the process state
When tracing on per-core mode, we are tracing all processes, which means that after hitt
[trace][intelpt] Support system-wide tracing [5] - Disable/enable per-core tracing based on the process state
When tracing on per-core mode, we are tracing all processes, which means that after hitting a breakpoint, our process will stop running (thus producing no more tracing data) but other processes will continue writing to our trace buffers. This causes a big data loss for our trace. As a way to remediate this, I'm adding some logic to pause and unpause tracing based on the target's state. The earlier we do it the better, however, I'm not adding the trigger at the earliest possible point for simplicity of this diff. Later we can improve that part.
Differential Revision: https://reviews.llvm.org/D124962
show more ...
|
| #
1f49714d |
| 03-May-2022 |
Walter Erquinigo <[email protected]> |
[trace][intelpt] Support system-wide tracing [4] - Support per core tracing on lldb-server
This diffs implements per-core tracing on lldb-server. It also includes tests that ensure that tracing can
[trace][intelpt] Support system-wide tracing [4] - Support per core tracing on lldb-server
This diffs implements per-core tracing on lldb-server. It also includes tests that ensure that tracing can be initiated from the client and that the jLLDBGetState ppacket returns the list of trace buffers per core.
This doesn't include any decoder changes.
Finally, this makes some little changes here and there improving the existing code.
A specific piece of code that can't reliably be tested is when tracing per core fails due to permissions. In this case we add a troubleshooting message and this is the manual test:
``` /proc/sys/kernel/perf_event_paranoid set to 1
(lldb) process trace start --per-core-tracing error: perf event syscall failed: Permission denied You might need that /proc/sys/kernel/perf_event_paranoid has a value of 0 or -1. ``
Differential Revision: https://reviews.llvm.org/D124858
show more ...
|
| #
26d83a43 |
| 10-May-2022 |
Walter Erquinigo <[email protected]> |
[NFC][lldb][trace] Use uint64_t when decoding and enconding json
llvm's json parser supports uint64_t, so let's better use it for the packets being sent between lldb and lldb-server instead of using
[NFC][lldb][trace] Use uint64_t when decoding and enconding json
llvm's json parser supports uint64_t, so let's better use it for the packets being sent between lldb and lldb-server instead of using int64_t as an intermediate type, which might be error-prone.
show more ...
|
| #
285b39a3 |
| 10-May-2022 |
Walter Erquinigo <[email protected]> |
Revert "[NFC][lldb][trace] Use uint64_t when decoding and enconding json"
This reverts commit 9d2dd6d7622335ba9c19b55ac7d463cf662cab0d.
Reverting because this exposes an issue in the uint64_t json
Revert "[NFC][lldb][trace] Use uint64_t when decoding and enconding json"
This reverts commit 9d2dd6d7622335ba9c19b55ac7d463cf662cab0d.
Reverting because this exposes an issue in the uint64_t json parser.
show more ...
|
| #
9d2dd6d7 |
| 10-May-2022 |
Walter Erquinigo <[email protected]> |
[NFC][lldb][trace] Use uint64_t when decoding and enconding json
llvm's json parser supports uint64_t, so let's better use it for the packets being sent between lldb and lldb-server instead of using
[NFC][lldb][trace] Use uint64_t when decoding and enconding json
llvm's json parser supports uint64_t, so let's better use it for the packets being sent between lldb and lldb-server instead of using int64_t as an intermediate type, which might be error-prone.
show more ...
|
| #
7b73de9e |
| 29-Apr-2022 |
Walter Erquinigo <[email protected]> |
[trace][intelpt] Support system-wide tracing [3] - Refactor IntelPTThreadTrace
I'm refactoring IntelPTThreadTrace into IntelPTSingleBufferTrace so that it can both single threads or single cores. In
[trace][intelpt] Support system-wide tracing [3] - Refactor IntelPTThreadTrace
I'm refactoring IntelPTThreadTrace into IntelPTSingleBufferTrace so that it can both single threads or single cores. In this diff I'm basically renaming the class, moving it to its own file, and removing all the pieces that are not used along with some basic cleanup.
Differential Revision: https://reviews.llvm.org/D124648
show more ...
|
|
Revision tags: llvmorg-14.0.3 |
|
| #
b8d1776f |
| 28-Apr-2022 |
Walter Erquinigo <[email protected]> |
[trace][intelpt] Support system-wide tracing [2] - Add a dummy --per-core-tracing option
This updates the documentation of the gdb-remote protocol, as well as the help messages, to include the new -
[trace][intelpt] Support system-wide tracing [2] - Add a dummy --per-core-tracing option
This updates the documentation of the gdb-remote protocol, as well as the help messages, to include the new --per-core-tracing option.
Differential Revision: https://reviews.llvm.org/D124640
show more ...
|
| #
5de0a3e9 |
| 27-Apr-2022 |
Walter Erquinigo <[email protected]> |
[trace][intelpt] Support system-wide tracing [1] - Add a method for accessing the list of logical core ids
In order to open perf events per core, we need to first get the list of core ids available
[trace][intelpt] Support system-wide tracing [1] - Add a method for accessing the list of logical core ids
In order to open perf events per core, we need to first get the list of core ids available in the system. So I'm adding a function that does that by parsing /proc/cpuinfo. That seems to be the simplest and most portable way to do that.
Besides that, I made a few refactors and renames to reflect better that the cpu info that we use in lldb-server comes from procfs.
Differential Revision: https://reviews.llvm.org/D124573
show more ...
|
|
Revision tags: llvmorg-14.0.2, llvmorg-14.0.1 |
|
| #
ae2aa2d2 |
| 06-Apr-2022 |
Martin Storsjö <[email protected]> |
[lldb] Silence GCC warnings about missing returns after fully covered switches. NFC.
This silences warnings like this:
lldb/source/Core/DebuggerEvents.cpp: In member function ‘llvm::StringRef lldb_
[lldb] Silence GCC warnings about missing returns after fully covered switches. NFC.
This silences warnings like this:
lldb/source/Core/DebuggerEvents.cpp: In member function ‘llvm::StringRef lldb_private::DiagnosticEventData::GetPrefix() const’: lldb/source/Core/DebuggerEvents.cpp:55:1: warning: control reaches end of non-void function [-Wreturn-type] 55 | }
Differential Revision: https://reviews.llvm.org/D123203
show more ...
|
| #
9b79187c |
| 22-Mar-2022 |
Jakob Johnson <[email protected]> |
[trace][intelpt] Server side changes for TSC to wall time conversion
Update the response schema of the TraceGetState packet and add Intel PT specific response structure that contains the TSC convers
[trace][intelpt] Server side changes for TSC to wall time conversion
Update the response schema of the TraceGetState packet and add Intel PT specific response structure that contains the TSC conversion, if it exists. The IntelPTCollector loads the TSC conversion and caches it to prevent unnecessary calls to perf_event_open. Move the TSC conversion calculation from Perf.h to TraceIntelPTGDBRemotePackets.h to remove dependency on Linux specific headers.
Differential Revision: https://reviews.llvm.org/D122246
show more ...
|
| #
e6c84f82 |
| 15-Mar-2022 |
Jakob Johnson <[email protected]> |
Add thin wrapper for perf_event_open API - Add PerfEvent class to handle creating ring buffers and handle the resources associated with a perf_event - Refactor IntelPT collection code to use this
Add thin wrapper for perf_event_open API - Add PerfEvent class to handle creating ring buffers and handle the resources associated with a perf_event - Refactor IntelPT collection code to use this new API - Add TSC to timestamp conversion logic with unittest
Differential Revision: https://reviews.llvm.org/D121734
show more ...
|
| #
22077627 |
| 15-Mar-2022 |
Jakob Johnson <[email protected]> |
Minor refactor and renaming: - Rename IntelPTManager class and files to IntelPTCollector - Change GetTimestampCounter API to general trace counter API, GetCounter
Differential Revision: http
Minor refactor and renaming: - Rename IntelPTManager class and files to IntelPTCollector - Change GetTimestampCounter API to general trace counter API, GetCounter
Differential Revision: https://reviews.llvm.org/D121711
show more ...
|