Revision tags: 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 |
|
#
2fe83274 |
| 07-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[lldb] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/
[lldb] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
f190ce62 |
| 07-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[lldb] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optiona
[lldb] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optional with std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, 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, llvmorg-14.0.6 |
|
#
c9fc4336 |
| 20-Jun-2022 |
Martin Storsjö <martin@martin.st> |
[lldb] Fix building with GCC 7
|
#
6a5355e8 |
| 14-Jun-2022 |
Walter Erquinigo <wallace@fb.com> |
[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 <wallace@fb.com> |
[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 <wallace@fb.com> |
[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 <wallace@fb.com> |
[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 ...
|
#
1f56f7fc |
| 12-May-2022 |
Walter Erquinigo <wallace@fb.com> |
[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 ...
|
#
1188faa7 |
| 05-May-2022 |
Walter Erquinigo <wallace@fb.com> |
[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 ...
|