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

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

93 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
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
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
[intel pt] Refactor parsing With the feedback I was getting in different diffs, I realized that splitting the parsing logic into two classes was not easy to deal with. I do see value in doing that, but I'd rather leave that as a refactor after most of the intel-pt logic is in place. Thus, I'm merging the common parser into the intel pt one, having thus only one that is fully aware of Intel PT during parsing and object creation. Besides, based on the feedback in https://reviews.llvm.org/D88769, I'm creating a ThreadIntelPT class that will be able to orchestrate decoding of its own trace and can handle the stop events correctly. This leaves the TraceIntelPT class as an initialization class that glues together different components. Right now it can initialize a trace session from a json file, and in the future will be able to initialize a trace session from a live process. Besides, I'm renaming SettingsParser to SessionParser, which I think is a better name, as the json object represents a trace session of possibly many processes. With the current set of targets, we have the following - Trace: main interface for dealing with trace sessions - TraceIntelPT: plugin Trace for dealing with intel pt sessions - TraceIntelPTSessionParser: a parser of a json trace session file that can create a corresponding TraceIntelPT instance along with Targets, ProcessTraces (to be created in https://reviews.llvm.org/D88769), and ThreadIntelPT threads. - ProcessTrace: (to be created in https://reviews.llvm.org/D88769) can handle the correct state of the traces as the user traverses the trace. I don't think there'll be a need an intel-pt specific implementation of this class. - ThreadIntelPT: a thread implementation that can handle the decoding of its own trace file, along with keeping track of the current position the user is looking at when doing reverse debugging. Differential Revision: https://reviews.llvm.org/D88841
2020-10-04 03:23:12 +08:00
TraceSessionFileParser.cpp
UnixSignals.cpp
UnwindAssembly.cpp
UnwindLLDB.cpp
LINK_LIBS
lldbBreakpoint
lldbCore
lldbExpression
lldbHost
lldbInterpreter
lldbSymbol
lldbUtility
lldbPluginExpressionParserClang
lldbPluginProcessUtility
LINK_COMPONENTS
Support
MC
)
add_dependencies(lldbTarget
LLDBTargetPropertiesGen
LLDBTargetPropertiesEnumGen)