maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Plugins/CMakeLists.txt

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

56 lines
1.8 KiB
CMake
Raw Normal View History

Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(ABI)
Move StopInfoOverride callback to the new architecture plugin This creates a new Architecture plugin and moves the stop info override callback to this place. The motivation for this is to remove complex dependencies from the ArchSpec class because it is used in a lot of places that (should) know nothing about Process instances and StopInfo objects. I also add a test for the functionality covered by the override callback. Differential Revision: https://reviews.llvm.org/D31172 llvm-svn: 316609
2017-10-26 05:05:31 +08:00
add_subdirectory(Architecture)
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(Disassembler)
add_subdirectory(DynamicLoader)
Fix cmake build. llvm-svn: 246746
2015-09-03 12:17:57 +08:00
add_subdirectory(ExpressionParser)
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(Instruction)
Fix cmake build for PluginInstrumentationRuntimeAddressSanitizer. llvm-svn: 219576
2014-10-12 04:11:18 +08:00
add_subdirectory(InstrumentationRuntime)
Add support for JIT debugging on Linux using the GDB JIT interface. Patch written with Keno Fischer. llvm-svn: 202956
2014-03-05 18:12:43 +08:00
add_subdirectory(JITLoader)
Add a new type of plugin: Language plugin The Language plugin is menat to answer language-specific questions that are not bound to the existence of a process. Those are still the domain of the LanguageRuntime plugin The Language plugin will, instead, answer questions such as providing language-specific data formatters or expression evaluation At the moment, the interface is hollowed out, and empty do-nothing plugins have been setup for ObjC, C++ and ObjC++ llvm-svn: 246212
2015-08-28 05:33:50 +08:00
add_subdirectory(Language)
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(LanguageRuntime)
ASan malloc/free history threads Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
2014-09-04 09:03:18 +08:00
add_subdirectory(MemoryHistory)
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(ObjectContainer)
add_subdirectory(ObjectFile)
add_subdirectory(OperatingSystem)
add_subdirectory(Platform)
add_subdirectory(Process)
Convert the ScriptInterpreter system to a plugin-based one. Previously embedded interpreters were handled as ad-hoc source files compiled into source/Interpreter. This made it hard to disable a specific interpreter, or to add support for other interpreters and allow the developer to choose which interpreter(s) were enabled for a particular build. This patch converts script interpreters over to a plugin-based system. Script interpreters now live in source/Plugins/ScriptInterpreter, and the canonical LLDB interpreter, ScriptInterpreterPython, is moved there as well. Any new code interfacing with the Python C API must live in this location from here on out. Additionally, generic code should never need to reference or make assumptions about the presence of a specific interpreter going forward. Differential Revision: http://reviews.llvm.org/D11431 Reviewed By: Greg Clayton llvm-svn: 243681
2015-07-31 04:28:07 +08:00
add_subdirectory(ScriptInterpreter)
Add StructuredData plugin type; showcase with new DarwinLog feature Take 2, with missing cmake line fixed. Build tested on Ubuntu 14.04 with clang-3.6. See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279202
2016-08-19 12:21:48 +08:00
add_subdirectory(StructuredData)
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(SymbolFile)
Tell CMake about the SystemRuntime plugin. This fixes CMake build on Darwin. llvm-svn: 196575
2013-12-06 17:32:46 +08:00
add_subdirectory(SystemRuntime)
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(SymbolVendor)
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
add_subdirectory(Trace)
[lldb] Move clang-based files out of Symbol Summary: This change represents the move of ClangASTImporter, ClangASTMetadata, ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h This explicitly removes knowledge of clang internals from lldbSymbol, moving towards a more generic core implementation of lldb. Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73661
2020-01-30 03:59:28 +08:00
add_subdirectory(TypeSystem)
Convert to UNIX line endings. llvm-svn: 191367
2013-09-25 18:37:32 +08:00
add_subdirectory(UnwindAssembly)
[lldb/Plugin] Generate LLDB_PLUGIN_DECLARE with CMake Generate the LLDB_PLUGIN_DECLARE macros with CMake and a def file. I'm landing D73067 in pieces so I can bisect what exactly is breaking the Windows bot.
2020-02-19 03:25:42 +08:00
set(LLDB_STRIPPED_PLUGINS)
get_property(LLDB_ALL_PLUGINS GLOBAL PROPERTY LLDB_PLUGINS)
set(LLDB_ENUM_PLUGINS "")
Re-land "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin" This patch changes the way we initialize and terminate the plugins in the system initializer. It uses an approach similar to LLVM's TARGETS_TO_BUILD with a def file that enumerates the plugins. Previous attempts to land this failed on the Windows bot because there's a dependency between the different process plugins. Apparently ProcessWindowsCommon needs to be initialized after all other process plugins but before ProcessGDBRemote. Differential revision: https://reviews.llvm.org/D73067
2020-02-19 11:13:45 +08:00
# FIXME: ProcessWindowsCommon needs to be initialized after all other process
# plugins but before ProcessGDBRemote.
set(LLDB_PROCESS_WINDOWS_PLUGIN "")
set(LLDB_PROCESS_GDB_PLUGIN "")
[lldb/Plugin] Generate LLDB_PLUGIN_DECLARE with CMake Generate the LLDB_PLUGIN_DECLARE macros with CMake and a def file. I'm landing D73067 in pieces so I can bisect what exactly is breaking the Windows bot.
2020-02-19 03:25:42 +08:00
foreach(p ${LLDB_ALL_PLUGINS})
# Strip lldbPlugin form the plugin name.
string(SUBSTRING ${p} 10 -1 pStripped)
if(${pStripped} MATCHES "^ScriptInterpreter*")
set(LLDB_ENUM_PLUGINS "${LLDB_ENUM_PLUGINS}LLDB_SCRIPT_PLUGIN(${pStripped})\n")
Re-land "[lldb/CMake] Auto-generate the Initialize and Terminate calls for plugin" This patch changes the way we initialize and terminate the plugins in the system initializer. It uses an approach similar to LLVM's TARGETS_TO_BUILD with a def file that enumerates the plugins. Previous attempts to land this failed on the Windows bot because there's a dependency between the different process plugins. Apparently ProcessWindowsCommon needs to be initialized after all other process plugins but before ProcessGDBRemote. Differential revision: https://reviews.llvm.org/D73067
2020-02-19 11:13:45 +08:00
elseif(${pStripped} STREQUAL "ProcessWindowsCommon")
set(LLDB_PROCESS_WINDOWS_PLUGIN "LLDB_PLUGIN(${pStripped})\n")
elseif(${pStripped} STREQUAL "ProcessGDBRemote")
set(LLDB_PROCESS_GDB_PLUGIN "LLDB_PLUGIN(${pStripped})\n")
[lldb/Plugin] Generate LLDB_PLUGIN_DECLARE with CMake Generate the LLDB_PLUGIN_DECLARE macros with CMake and a def file. I'm landing D73067 in pieces so I can bisect what exactly is breaking the Windows bot.
2020-02-19 03:25:42 +08:00
else()
set(LLDB_ENUM_PLUGINS "${LLDB_ENUM_PLUGINS}LLDB_PLUGIN(${pStripped})\n")
endif()
endforeach(p)
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/Plugins.def.in
${CMAKE_CURRENT_BINARY_DIR}/Plugins.def
)
set_property(GLOBAL PROPERTY LLDB_PLUGINS_INCLUDE_DIR ${CMAKE_CURRENT_BINARY_DIR})