llvm-project/lldb/source/Commands/CommandObjectTrace.h

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

52 lines
1.7 KiB
C
Raw Normal View History

Add a "Trace" plug-in to LLDB to add process trace support in stages. This is the first in a series of patches that will adds a new processor trace plug-in to LLDB. The idea for this first patch to to add the plug-in interface with simple commands for the trace files that can "load" and "dump" the trace information. We can test the functionality and ensure people are happy with the way things are done and how things are organized before moving on to adding more functionality. Processor trace information can be view in a few different ways: - post mortem where a trace is saved off that can be viewed later in the debugger - gathered while a process is running and allow the user to step back in time (with no variables, memory or registers) to see how each thread arrived at where it is currently stopped. This patch attempts to start with the first solution of loading a trace file after the fact. The idea is that we will use a JSON file to load the trace information. JSON allows us to specify information about the trace like: - plug-in name in LLDB - path to trace file - shared library load information so we can re-create a target and symbolicate the information in the trace - any other info that the trace plug-in will need to be able to successfully parse the trace information - cpu type - version info - ??? A new "trace" command was added at the top level of the LLDB commmands: - "trace load" - "trace dump" I did this because if we load trace information we don't need to have a process and we might end up creating a new target for the trace information that will become active. If anyone has any input on where this would be better suited, please let me know. Walter Erquinigo will end up filling in the Intel PT specific plug-in so that it works and is tested once we can agree that the direction of this patch is the correct one, so please feel free to chime in with ideas on comments! Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D85705
2020-08-18 08:21:52 +08:00
//===-- CommandObjectTrace.h ------------------------------------*- C++ -*-===//
//
// 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
//
//===----------------------------------------------------------------------===//
#ifndef LLDB_SOURCE_COMMANDS_COMMANDOBJECTTRACE_H
#define LLDB_SOURCE_COMMANDS_COMMANDOBJECTTRACE_H
#include "CommandObjectThreadUtil.h"
Add a "Trace" plug-in to LLDB to add process trace support in stages. This is the first in a series of patches that will adds a new processor trace plug-in to LLDB. The idea for this first patch to to add the plug-in interface with simple commands for the trace files that can "load" and "dump" the trace information. We can test the functionality and ensure people are happy with the way things are done and how things are organized before moving on to adding more functionality. Processor trace information can be view in a few different ways: - post mortem where a trace is saved off that can be viewed later in the debugger - gathered while a process is running and allow the user to step back in time (with no variables, memory or registers) to see how each thread arrived at where it is currently stopped. This patch attempts to start with the first solution of loading a trace file after the fact. The idea is that we will use a JSON file to load the trace information. JSON allows us to specify information about the trace like: - plug-in name in LLDB - path to trace file - shared library load information so we can re-create a target and symbolicate the information in the trace - any other info that the trace plug-in will need to be able to successfully parse the trace information - cpu type - version info - ??? A new "trace" command was added at the top level of the LLDB commmands: - "trace load" - "trace dump" I did this because if we load trace information we don't need to have a process and we might end up creating a new target for the trace information that will become active. If anyone has any input on where this would be better suited, please let me know. Walter Erquinigo will end up filling in the Intel PT specific plug-in so that it works and is tested once we can agree that the direction of this patch is the correct one, so please feel free to chime in with ideas on comments! Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D85705
2020-08-18 08:21:52 +08:00
namespace lldb_private {
class CommandObjectTrace : public CommandObjectMultiword {
public:
CommandObjectTrace(CommandInterpreter &interpreter);
~CommandObjectTrace() override;
};
/// This class works by delegating the logic to the actual trace plug-in that
/// can support the current process.
class CommandObjectTraceProxy : public CommandObjectProxy {
public:
CommandObjectTraceProxy(bool live_debug_session_only,
CommandInterpreter &interpreter, const char *name,
const char *help = nullptr,
const char *syntax = nullptr, uint32_t flags = 0)
: CommandObjectProxy(interpreter, name, help, syntax, flags),
m_live_debug_session_only(live_debug_session_only) {}
protected:
virtual lldb::CommandObjectSP GetDelegateCommand(Trace &trace) = 0;
llvm::Expected<lldb::CommandObjectSP> DoGetProxyCommandObject();
CommandObject *GetProxyCommandObject() override;
private:
llvm::StringRef GetUnsupportedError() override { return m_delegate_error; }
bool m_live_debug_session_only;
lldb::CommandObjectSP m_delegate_sp;
std::string m_delegate_error;
};
Add a "Trace" plug-in to LLDB to add process trace support in stages. This is the first in a series of patches that will adds a new processor trace plug-in to LLDB. The idea for this first patch to to add the plug-in interface with simple commands for the trace files that can "load" and "dump" the trace information. We can test the functionality and ensure people are happy with the way things are done and how things are organized before moving on to adding more functionality. Processor trace information can be view in a few different ways: - post mortem where a trace is saved off that can be viewed later in the debugger - gathered while a process is running and allow the user to step back in time (with no variables, memory or registers) to see how each thread arrived at where it is currently stopped. This patch attempts to start with the first solution of loading a trace file after the fact. The idea is that we will use a JSON file to load the trace information. JSON allows us to specify information about the trace like: - plug-in name in LLDB - path to trace file - shared library load information so we can re-create a target and symbolicate the information in the trace - any other info that the trace plug-in will need to be able to successfully parse the trace information - cpu type - version info - ??? A new "trace" command was added at the top level of the LLDB commmands: - "trace load" - "trace dump" I did this because if we load trace information we don't need to have a process and we might end up creating a new target for the trace information that will become active. If anyone has any input on where this would be better suited, please let me know. Walter Erquinigo will end up filling in the Intel PT specific plug-in so that it works and is tested once we can agree that the direction of this patch is the correct one, so please feel free to chime in with ideas on comments! Reviewed By: clayborg Differential Revision: https://reviews.llvm.org/D85705
2020-08-18 08:21:52 +08:00
} // namespace lldb_private
#endif // LLDB_SOURCE_COMMANDS_COMMANDOBJECTTRACE_H