2019-07-30 01:22:10 +08:00
|
|
|
lldb_tablegen(TargetProperties.inc -gen-lldb-property-defs
|
|
|
|
SOURCE TargetProperties.td
|
2019-07-27 02:14:08 +08:00
|
|
|
TARGET LLDBTargetPropertiesGen)
|
|
|
|
|
2019-07-30 01:22:10 +08:00
|
|
|
lldb_tablegen(TargetPropertiesEnum.inc -gen-lldb-property-enum-defs
|
|
|
|
SOURCE TargetProperties.td
|
2019-07-27 02:14:08 +08:00
|
|
|
TARGET LLDBTargetPropertiesEnumGen)
|
|
|
|
|
2013-09-25 18:37:32 +08:00
|
|
|
add_lldb_library(lldbTarget
|
|
|
|
ABI.cpp
|
2020-02-05 00:53:26 +08:00
|
|
|
AssertFrameRecognizer.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
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
|
2020-01-22 22:15:00 +08:00
|
|
|
JITLoader.cpp
|
|
|
|
JITLoaderList.cpp
|
2015-08-28 05:45:59 +08:00
|
|
|
Language.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
LanguageRuntime.cpp
|
|
|
|
Memory.cpp
|
2014-09-04 09:03:18 +08:00
|
|
|
MemoryHistory.cpp
|
2019-10-26 06:18:51 +08:00
|
|
|
MemoryRegionInfo.cpp
|
2017-02-15 03:06:07 +08:00
|
|
|
ModuleCache.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
OperatingSystem.cpp
|
|
|
|
PathMappingList.cpp
|
|
|
|
Platform.cpp
|
|
|
|
Process.cpp
|
2020-10-15 01:25:39 +08:00
|
|
|
ProcessTrace.cpp
|
2013-12-13 08:29:16 +08:00
|
|
|
Queue.cpp
|
|
|
|
QueueItem.cpp
|
|
|
|
QueueList.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
RegisterContext.cpp
|
2020-03-09 21:36:15 +08:00
|
|
|
RegisterContextUnwind.cpp
|
2017-02-15 03:06:07 +08:00
|
|
|
RegisterNumber.cpp
|
Extract common PlatformPOSIX/Windows code into a separate class
Summary:
The two classes contained a lot of duplicated code, but there wasn't a
good place to factor it to. It couldn't be the base Platform class,
since we also have platforms which are only remote (such as
PlatformGDBRemoteServer), and so it did not make sense for those to have
an m_remote_platform member.
This patch creates a new class, RemoteAwarePlatform, which can serve as
a base class for platforms which can both serve as a host, and forward
actions to a remote system. It is motivated partly by D56232 (which was
about to add a bunch of additional duplicated methods), and partly by my
own need to modify a function which happens to be implemented in both
places identically.
The patch moves the methods which are trivially identical in the two
classes into the common base class, there were one or two more methods
which could probably be merged into one, but this wasn't completely
trivial, so I did not attempt to do that now.
Reviewers: jingham, zturner, clayborg, asmith
Subscribers: emaste, mgorny, Hui, lldb-commits
Differential Revision: https://reviews.llvm.org/D58052
llvm-svn: 353812
2019-02-12 17:27:24 +08:00
|
|
|
RemoteAwarePlatform.cpp
|
2013-12-06 16:49:14 +08:00
|
|
|
SectionLoadHistory.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
SectionLoadList.cpp
|
|
|
|
StackFrame.cpp
|
|
|
|
StackFrameList.cpp
|
2018-10-31 12:00:22 +08:00
|
|
|
StackFrameRecognizer.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
StackID.cpp
|
|
|
|
StopInfo.cpp
|
2016-08-19 12:21:48 +08:00
|
|
|
StructuredDataPlugin.cpp
|
2013-11-05 11:57:19 +08:00
|
|
|
SystemRuntime.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
Target.cpp
|
|
|
|
TargetList.cpp
|
|
|
|
Thread.cpp
|
2014-09-06 04:11:22 +08:00
|
|
|
ThreadCollection.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
ThreadList.cpp
|
|
|
|
ThreadPlan.cpp
|
|
|
|
ThreadPlanBase.cpp
|
|
|
|
ThreadPlanCallFunction.cpp
|
Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a function call on target via register manipulation
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support.
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.
In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation.
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter.
The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.
Reviewers: jingham, spyffe
Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427
Differential Revision: http://reviews.llvm.org/D9404
llvm-svn: 242137
2015-07-14 18:56:58 +08:00
|
|
|
ThreadPlanCallFunctionUsingABI.cpp
|
2016-08-19 12:21:48 +08:00
|
|
|
ThreadPlanCallOnFunctionExit.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
ThreadPlanCallUserExpression.cpp
|
2014-09-30 23:58:56 +08:00
|
|
|
ThreadPlanPython.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
ThreadPlanRunToAddress.cpp
|
|
|
|
ThreadPlanShouldStopHere.cpp
|
|
|
|
ThreadPlanStepInRange.cpp
|
|
|
|
ThreadPlanStepInstruction.cpp
|
|
|
|
ThreadPlanStepOut.cpp
|
|
|
|
ThreadPlanStepOverBreakpoint.cpp
|
|
|
|
ThreadPlanStepOverRange.cpp
|
|
|
|
ThreadPlanStepRange.cpp
|
|
|
|
ThreadPlanStepThrough.cpp
|
|
|
|
ThreadPlanStepUntil.cpp
|
|
|
|
ThreadPlanTracer.cpp
|
2020-03-11 07:18:11 +08:00
|
|
|
ThreadPlanStack.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
ThreadSpec.cpp
|
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
|
2021-06-30 05:03:30 +08:00
|
|
|
TraceInstructionDumper.cpp
|
2013-09-25 18:37:32 +08:00
|
|
|
UnixSignals.cpp
|
|
|
|
UnwindAssembly.cpp
|
2020-03-09 21:36:15 +08:00
|
|
|
UnwindLLDB.cpp
|
2017-02-01 04:43:05 +08:00
|
|
|
|
|
|
|
LINK_LIBS
|
|
|
|
lldbBreakpoint
|
|
|
|
lldbCore
|
|
|
|
lldbExpression
|
|
|
|
lldbHost
|
|
|
|
lldbInterpreter
|
|
|
|
lldbSymbol
|
|
|
|
lldbUtility
|
|
|
|
lldbPluginProcessUtility
|
|
|
|
|
|
|
|
LINK_COMPONENTS
|
|
|
|
Support
|
2020-03-03 20:09:35 +08:00
|
|
|
MC
|
2013-09-25 18:37:32 +08:00
|
|
|
)
|
2019-07-26 05:36:37 +08:00
|
|
|
|
2019-07-27 02:14:08 +08:00
|
|
|
add_dependencies(lldbTarget
|
|
|
|
LLDBTargetPropertiesGen
|
|
|
|
LLDBTargetPropertiesEnumGen)
|