llvm-project/lldb/source/Target/TraceExporter.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

32 lines
996 B
C++
Raw Normal View History

[trace] Add the definition of a TraceExporter plugin Copying from the inline documentation: ``` Trace exporter plug-ins operate on traces, converting the trace data provided by an \a lldb_private::TraceCursor into a different format that can be digested by other tools, e.g. Chrome Trace Event Profiler. Trace exporters are supposed to operate on an architecture-agnostic fashion, as a TraceCursor, which feeds the data, hides the actual trace technology being used. ``` I want to use this to make the code in https://reviews.llvm.org/D105741 a plug-in. I also imagine that there will be more and more exporters being implemented, as an exporter creates something useful out of trace data. And tbh I don't want to keep adding more stuff to the lldb/Target folder. This is the minimal definition for a TraceExporter plugin. I plan to use this with the following commands: - thread trace export <plug-in name> [plug-in specific args] - This command would support autocompletion of plug-in names - thread trace export list - This command would list the available trace exporter plug-ins I don't plan to create yet a "process trace export" because it's easier to start analyzing the trace of a given thread than of the entire process. When we need a process-level command, we can implement it. I also don't plan to force each "export" command implementation to support multiple threads (for example, "thread trace start 1 2 3" or "thread trace start all" operate on many threads simultaneously). The reason is that the format used by the exporter might or might not support multiple threads, so I'm leaving this decision to each trace exporter plug-in. Differential Revision: https://reviews.llvm.org/D106501
2021-07-22 05:46:51 +08:00
//===-- TraceExporter.cpp -------------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "lldb/Target/TraceExporter.h"
#include "lldb/Core/PluginManager.h"
using namespace lldb;
using namespace lldb_private;
using namespace llvm;
static Error createInvalidPlugInError(StringRef plugin_name) {
return createStringError(
std::errc::invalid_argument,
"no trace expoter plug-in matches the specified type: \"%s\"",
plugin_name.data());
}
Expected<lldb::TraceExporterUP>
TraceExporter::FindPlugin(llvm::StringRef name) {
[trace] Add the definition of a TraceExporter plugin Copying from the inline documentation: ``` Trace exporter plug-ins operate on traces, converting the trace data provided by an \a lldb_private::TraceCursor into a different format that can be digested by other tools, e.g. Chrome Trace Event Profiler. Trace exporters are supposed to operate on an architecture-agnostic fashion, as a TraceCursor, which feeds the data, hides the actual trace technology being used. ``` I want to use this to make the code in https://reviews.llvm.org/D105741 a plug-in. I also imagine that there will be more and more exporters being implemented, as an exporter creates something useful out of trace data. And tbh I don't want to keep adding more stuff to the lldb/Target folder. This is the minimal definition for a TraceExporter plugin. I plan to use this with the following commands: - thread trace export <plug-in name> [plug-in specific args] - This command would support autocompletion of plug-in names - thread trace export list - This command would list the available trace exporter plug-ins I don't plan to create yet a "process trace export" because it's easier to start analyzing the trace of a given thread than of the entire process. When we need a process-level command, we can implement it. I also don't plan to force each "export" command implementation to support multiple threads (for example, "thread trace start 1 2 3" or "thread trace start all" operate on many threads simultaneously). The reason is that the format used by the exporter might or might not support multiple threads, so I'm leaving this decision to each trace exporter plug-in. Differential Revision: https://reviews.llvm.org/D106501
2021-07-22 05:46:51 +08:00
if (auto create_callback =
PluginManager::GetTraceExporterCreateCallback(name))
return create_callback();
return createInvalidPlugInError(name);
[trace] Add the definition of a TraceExporter plugin Copying from the inline documentation: ``` Trace exporter plug-ins operate on traces, converting the trace data provided by an \a lldb_private::TraceCursor into a different format that can be digested by other tools, e.g. Chrome Trace Event Profiler. Trace exporters are supposed to operate on an architecture-agnostic fashion, as a TraceCursor, which feeds the data, hides the actual trace technology being used. ``` I want to use this to make the code in https://reviews.llvm.org/D105741 a plug-in. I also imagine that there will be more and more exporters being implemented, as an exporter creates something useful out of trace data. And tbh I don't want to keep adding more stuff to the lldb/Target folder. This is the minimal definition for a TraceExporter plugin. I plan to use this with the following commands: - thread trace export <plug-in name> [plug-in specific args] - This command would support autocompletion of plug-in names - thread trace export list - This command would list the available trace exporter plug-ins I don't plan to create yet a "process trace export" because it's easier to start analyzing the trace of a given thread than of the entire process. When we need a process-level command, we can implement it. I also don't plan to force each "export" command implementation to support multiple threads (for example, "thread trace start 1 2 3" or "thread trace start all" operate on many threads simultaneously). The reason is that the format used by the exporter might or might not support multiple threads, so I'm leaving this decision to each trace exporter plug-in. Differential Revision: https://reviews.llvm.org/D106501
2021-07-22 05:46:51 +08:00
}