llvm-project/lldb/source/Target/CMakeLists.txt

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

96 lines
2.0 KiB
CMake
Raw Normal View History

lldb_tablegen(TargetProperties.inc -gen-lldb-property-defs
SOURCE TargetProperties.td
TARGET LLDBTargetPropertiesGen)
lldb_tablegen(TargetPropertiesEnum.inc -gen-lldb-property-enum-defs
SOURCE TargetProperties.td
TARGET LLDBTargetPropertiesEnumGen)
add_lldb_library(lldbTarget
ABI.cpp
AssertFrameRecognizer.cpp
DynamicRegisterInfo.cpp
ExecutionContext.cpp
LLDB AddressSanitizer instrumentation runtime plugin, breakpint on error and report data extraction Reviewed at http://reviews.llvm.org/D5592 This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API. More precisely this patch... adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable adds a collection of these plugins into the Process class AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now) SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream adds a test case for all of this I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose. Kuba llvm-svn: 219546
2014-10-11 07:43:03 +08:00
InstrumentationRuntime.cpp
InstrumentationRuntimeStopInfo.cpp
JITLoader.cpp
JITLoaderList.cpp
Language.cpp
LanguageRuntime.cpp
Memory.cpp
MemoryHistory.cpp
lldb/minidump: Refactor memory region computation code The goal of this refactor is to enable ProcessMinidump to take into account the loaded modules and their sections when computing the permissions of various ranges of memory, as discussed in D66638. This patch moves some of the responsibility for computing the ranges from MinidumpParser into ProcessMinidump. MinidumpParser still does the parsing, but ProcessMinidump becomes responsible for answering the actual queries about memory ranges. This will enable it (in a follow-up patch) to augment the information obtained from the parser with data obtained from actual object files. The changes in the actual code are fairly straight-forward and just involve moving code around. MinidumpParser::GetMemoryRegions is renamed to BuildMemoryRegions to emphasize that it does no caching. The only new thing is the additional bool flag returned from this function. This indicates whether the returned regions describe all memory mapped into the target process. Data obtained from /proc/maps and the MemoryInfoList stream is considered to be exhaustive. Data obtained from Memory(64)List is not. This will be used to determine whether we need to augment the data or not. This reshuffle means that it is no longer possible/easy to test some of this code via unit tests, as constructing a ProcessMinidump instance is hard. Instead, I update the unit tests to only test the parsing of the actual data, and test the answering of queries through a lit test using the "memory region" command. The patch also includes some tweaks to the MemoryRegion class to make the unit tests easier to write. Reviewers: amccarth, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D69035
2019-10-26 06:18:51 +08:00
MemoryRegionInfo.cpp
ModuleCache.cpp
OperatingSystem.cpp
PathMappingList.cpp
Platform.cpp
Process.cpp
ProcessTrace.cpp
Queue.cpp
QueueItem.cpp
QueueList.cpp
RegisterContext.cpp
RegisterContextUnwind.cpp
RegisterNumber.cpp
RemoteAwarePlatform.cpp
SectionLoadHistory.cpp
SectionLoadList.cpp
StackFrame.cpp
StackFrameList.cpp
StackFrameRecognizer.cpp
StackID.cpp
StopInfo.cpp
StructuredDataPlugin.cpp
SystemRuntime.cpp
Target.cpp
TargetList.cpp
Thread.cpp
ThreadCollection.cpp
ThreadList.cpp
ThreadPlan.cpp
ThreadPlanBase.cpp
ThreadPlanCallFunction.cpp
ThreadPlanCallFunctionUsingABI.cpp
ThreadPlanCallOnFunctionExit.cpp
ThreadPlanCallUserExpression.cpp
ThreadPlanPython.cpp
ThreadPlanRunToAddress.cpp
ThreadPlanShouldStopHere.cpp
ThreadPlanStepInRange.cpp
ThreadPlanStepInstruction.cpp
ThreadPlanStepOut.cpp
ThreadPlanStepOverBreakpoint.cpp
ThreadPlanStepOverRange.cpp
ThreadPlanStepRange.cpp
ThreadPlanStepThrough.cpp
ThreadPlanStepUntil.cpp
ThreadPlanTracer.cpp
ThreadPlanStack.cpp
ThreadSpec.cpp
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
Trace.cpp
[trace] Add a TraceCursor class As a follow up of D103588, I'm reinitiating the discussion with a new proposal for traversing instructions in a trace which uses the feedback gotten in that diff. See the embedded documentation in TraceCursor for more information. The idea is to offer an OOP way to traverse instructions exposing a minimal interface that makes no assumptions on: - the number of instructions in the trace (i.e. having indices for instructions might be impractical for gigantic intel-pt traces, as it would require to decode the entire trace). This renders the use of indices to point to instructions impractical. Traces are big and expensive, and the consumer should try to do look linear lookups (forwards and/or backwards) and avoid random accesses (the API could be extended though, but for now I want to dicard that funcionality and leave the API extensible if needed). - the way the instructions are represented internally by each Trace plug-in. They could be mmap'ed from a file, exist in plain vector or generated on the fly as the user requests the data. - the actual data structure used internally for each plug-in. Ideas like having a struct TraceInstruction have been discarded because that would make the plug-in follow a certain data type, which might be costly. Instead, the user can ask the cursor for each independent property of the instruction it's pointing at. The way to get a cursor is to ask Trace.h for the end or being cursor or a thread's trace. There are some benefits of this approach: - there's little cost to create a cursor, and this allows for lazily decoding a trace as the user requests data. - each trace plug-in could decide how to cache the instructions it generates. For example, if a trace is small, it might decide to keep everything in memory, or if the trace is massive, it might decide to keep around the last thousands of instructions to speed up local searches. - a cursor can outlive a stop point, which makes trace comparison for live processes feasible. An application of this is to compare profiling data of two runs of the same function, which should be doable with intel pt. Differential Revision: https://reviews.llvm.org/D104422
2021-06-17 05:09:46 +08:00
TraceCursor.cpp
[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
TraceInstructionDumper.cpp
UnixSignals.cpp
UnwindAssembly.cpp
UnwindLLDB.cpp
LINK_LIBS
lldbBreakpoint
lldbCore
lldbExpression
lldbHost
lldbInterpreter
lldbSymbol
lldbUtility
lldbPluginProcessUtility
LINK_COMPONENTS
Support
MC
)
add_dependencies(lldbTarget
LLDBTargetPropertiesGen
LLDBTargetPropertiesEnumGen)