2015-03-31 21:03:22 +00:00
|
|
|
//===-- SystemInitializerFull.cpp -------------------------------*- C++ -*-===//
|
|
|
|
|
//
|
2019-01-19 08:50:56 +00:00
|
|
|
// 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
|
2015-03-31 21:03:22 +00:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2018-05-25 20:28:16 +00:00
|
|
|
#include "SystemInitializerFull.h"
|
2015-07-30 20:28:07 +00:00
|
|
|
#include "lldb/API/SBCommandInterpreter.h"
|
2019-12-10 08:54:30 -08:00
|
|
|
#include "lldb/Host/Config.h"
|
2015-07-30 20:28:07 +00:00
|
|
|
|
2019-12-13 10:37:33 -08:00
|
|
|
#if LLDB_ENABLE_PYTHON
|
2015-07-30 20:28:07 +00:00
|
|
|
#include "Plugins/ScriptInterpreter/Python/ScriptInterpreterPython.h"
|
|
|
|
|
#endif
|
|
|
|
|
|
2019-12-07 15:49:35 -08:00
|
|
|
#if LLDB_ENABLE_LUA
|
|
|
|
|
#include "Plugins/ScriptInterpreter/Lua/ScriptInterpreterLua.h"
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
#include "lldb/Core/Debugger.h"
|
|
|
|
|
#include "lldb/Host/Host.h"
|
|
|
|
|
#include "lldb/Initialization/SystemInitializerCommon.h"
|
2015-07-30 20:28:07 +00:00
|
|
|
#include "lldb/Interpreter/CommandInterpreter.h"
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
#include "lldb/Symbol/TypeSystemClang.h"
|
2017-06-29 14:32:17 +00:00
|
|
|
#include "lldb/Utility/Timer.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
|
|
|
|
|
#include "Plugins/ABI/MacOSX-arm/ABIMacOSX_arm.h"
|
|
|
|
|
#include "Plugins/ABI/MacOSX-arm64/ABIMacOSX_arm64.h"
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
#include "Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.h"
|
2019-10-17 15:18:03 +00:00
|
|
|
#include "Plugins/ABI/SysV-arc/ABISysV_arc.h"
|
2015-04-29 10:49:45 +00:00
|
|
|
#include "Plugins/ABI/SysV-arm/ABISysV_arm.h"
|
2015-04-29 11:52:35 +00:00
|
|
|
#include "Plugins/ABI/SysV-arm64/ABISysV_arm64.h"
|
2015-12-10 17:53:07 +00:00
|
|
|
#include "Plugins/ABI/SysV-hexagon/ABISysV_hexagon.h"
|
2015-06-25 17:50:15 +00:00
|
|
|
#include "Plugins/ABI/SysV-i386/ABISysV_i386.h"
|
2015-06-18 07:02:10 +00:00
|
|
|
#include "Plugins/ABI/SysV-mips/ABISysV_mips.h"
|
2015-06-19 04:25:07 +00:00
|
|
|
#include "Plugins/ABI/SysV-mips64/ABISysV_mips64.h"
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
#include "Plugins/ABI/SysV-ppc/ABISysV_ppc.h"
|
|
|
|
|
#include "Plugins/ABI/SysV-ppc64/ABISysV_ppc64.h"
|
2016-04-14 14:28:34 +00:00
|
|
|
#include "Plugins/ABI/SysV-s390x/ABISysV_s390x.h"
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
#include "Plugins/ABI/SysV-x86_64/ABISysV_x86_64.h"
|
2019-06-24 18:21:05 +00:00
|
|
|
#include "Plugins/ABI/Windows-x86_64/ABIWindows_x86_64.h"
|
2017-10-25 21:05:31 +00:00
|
|
|
#include "Plugins/Architecture/Arm/ArchitectureArm.h"
|
2018-12-13 14:28:25 +00:00
|
|
|
#include "Plugins/Architecture/Mips/ArchitectureMips.h"
|
2018-03-12 21:17:04 +00:00
|
|
|
#include "Plugins/Architecture/PPC64/ArchitecturePPC64.h"
|
2020-01-21 15:14:28 -08:00
|
|
|
#include "Plugins/Disassembler/LLVMC/DisassemblerLLVMC.h"
|
2016-07-21 08:30:55 +00:00
|
|
|
#include "Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.h"
|
2016-03-29 15:00:26 +00:00
|
|
|
#include "Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.h"
|
|
|
|
|
#include "Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h"
|
2016-06-29 13:58:27 +00:00
|
|
|
#include "Plugins/DynamicLoader/Static/DynamicLoaderStatic.h"
|
2016-03-29 15:00:26 +00:00
|
|
|
#include "Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.h"
|
2019-05-06 19:38:24 +00:00
|
|
|
#include "Plugins/Instruction/ARM/EmulateInstructionARM.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
#include "Plugins/Instruction/ARM64/EmulateInstructionARM64.h"
|
2019-05-06 19:38:24 +00:00
|
|
|
#include "Plugins/Instruction/MIPS/EmulateInstructionMIPS.h"
|
|
|
|
|
#include "Plugins/Instruction/MIPS64/EmulateInstructionMIPS64.h"
|
2018-02-27 18:42:46 +00:00
|
|
|
#include "Plugins/Instruction/PPC64/EmulateInstructionPPC64.h"
|
2020-01-21 14:43:46 -08:00
|
|
|
#include "Plugins/InstrumentationRuntime/ASan/InstrumentationRuntimeASan.h"
|
2020-01-21 15:01:36 -08:00
|
|
|
#include "Plugins/InstrumentationRuntime/MainThreadChecker/InstrumentationRuntimeMainThreadChecker.h"
|
2020-01-21 14:50:36 -08:00
|
|
|
#include "Plugins/InstrumentationRuntime/TSan/InstrumentationRuntimeTSan.h"
|
2020-01-21 14:55:13 -08:00
|
|
|
#include "Plugins/InstrumentationRuntime/UBSan/InstrumentationRuntimeUBSan.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
#include "Plugins/JITLoader/GDB/JITLoaderGDB.h"
|
2015-09-01 18:22:39 +00:00
|
|
|
#include "Plugins/Language/CPlusPlus/CPlusPlusLanguage.h"
|
|
|
|
|
#include "Plugins/Language/ObjC/ObjCLanguage.h"
|
|
|
|
|
#include "Plugins/Language/ObjCPlusPlus/ObjCPlusPlusLanguage.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
#include "Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.h"
|
2020-01-21 22:20:48 -08:00
|
|
|
#include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntime.h"
|
2015-04-09 16:49:25 +00:00
|
|
|
#include "Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
#include "Plugins/MemoryHistory/asan/MemoryHistoryASan.h"
|
2019-05-02 18:11:44 +00:00
|
|
|
#include "Plugins/ObjectContainer/BSD-Archive/ObjectContainerBSDArchive.h"
|
|
|
|
|
#include "Plugins/ObjectContainer/Universal-Mach-O/ObjectContainerUniversalMachO.h"
|
Re-commit "Introduce ObjectFileBreakpad"
This re-commits r348592, which was reverted due to a failing test on
macos.
The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).
It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.
The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348773
2018-12-10 17:16:38 +00:00
|
|
|
#include "Plugins/ObjectFile/Breakpad/ObjectFileBreakpad.h"
|
2018-05-24 12:44:18 +00:00
|
|
|
#include "Plugins/ObjectFile/ELF/ObjectFileELF.h"
|
|
|
|
|
#include "Plugins/ObjectFile/Mach-O/ObjectFileMachO.h"
|
|
|
|
|
#include "Plugins/ObjectFile/PECOFF/ObjectFilePECOFF.h"
|
[LLDB] Add ObjectFileWasm plugin for WebAssembly debugging
Summary:
This is the first in a series of patches to enable LLDB debugging of
WebAssembly targets.
Current versions of Clang emit (partial) DWARF debug information in WebAssembly
modules and we can leverage this debug information to give LLDB the ability to
do source-level debugging of Wasm code that runs in a WebAssembly engine.
A way to do this could be to use the remote debugging functionalities provided
by LLDB via the GDB-remote protocol. Remote debugging can indeed be useful not
only to connect a debugger to a process running on a remote machine, but also to
connect the debugger to a managed VM or script engine that runs locally,
provided that the engine implements a GDB-remote stub that offers the ability to
access the engine runtime internal state.
To make this work, the GDB-remote protocol would need to be extended with a few
Wasm-specific custom query commands, used to access aspects of the Wasm engine
state (like the Wasm memory, Wasm local and global variables, and so on).
Furthermore, the DWARF format would need to be enriched with a few Wasm-specific
extensions, here detailed: https://yurydelendik.github.io/webassembly-dwarf.
This CL introduce classes **ObjectFileWasm**, a file plugin to represent a Wasm
module loaded in a debuggee process. It knows how to parse Wasm modules and
store the Code section and the DWARF-specific sections.
Reviewers: jasonmolenda, clayborg, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71575
2020-01-15 15:29:24 -08:00
|
|
|
#include "Plugins/ObjectFile/wasm/ObjectFileWasm.h"
|
2016-06-29 13:58:27 +00:00
|
|
|
#include "Plugins/OperatingSystem/Python/OperatingSystemPython.h"
|
|
|
|
|
#include "Plugins/Platform/Android/PlatformAndroid.h"
|
|
|
|
|
#include "Plugins/Platform/FreeBSD/PlatformFreeBSD.h"
|
|
|
|
|
#include "Plugins/Platform/Linux/PlatformLinux.h"
|
|
|
|
|
#include "Plugins/Platform/MacOSX/PlatformMacOSX.h"
|
|
|
|
|
#include "Plugins/Platform/MacOSX/PlatformRemoteiOS.h"
|
|
|
|
|
#include "Plugins/Platform/NetBSD/PlatformNetBSD.h"
|
[LLDB] OpenBSD support
Summary:
Add basic OpenBSD support. This is enough to be able to analyze core dumps for OpenBSD/amd64, OpenBSD/arm, OpenBSD/arm64 and OpenBSD/i386.
Note that part of the changes to source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp fix a bug that probably affects other platforms as well. The GetProgramHeaderByIndex() interface use 1-based indices, but in some case when looping over the headers the, the loop starts at 0 and misses the last header. This caused problems on OpenBSD since OpenBSD core dumps have the PT_NOTE segment as the last program header.
Reviewers: joerg, labath, krytarowski
Reviewed By: krytarowski
Subscribers: aemerson, emaste, rengolin, srhines, krytarowski, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31131
llvm-svn: 298810
2017-03-26 15:34:57 +00:00
|
|
|
#include "Plugins/Platform/OpenBSD/PlatformOpenBSD.h"
|
2016-06-29 13:58:27 +00:00
|
|
|
#include "Plugins/Platform/Windows/PlatformWindows.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
#include "Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h"
|
|
|
|
|
#include "Plugins/Process/elf-core/ProcessElfCore.h"
|
|
|
|
|
#include "Plugins/Process/gdb-remote/ProcessGDBRemote.h"
|
2018-05-22 16:33:43 +00:00
|
|
|
#include "Plugins/Process/mach-core/ProcessMachCore.h"
|
Minidump plugin: Adding ProcessMinidump, ThreadMinidump and register the plugin in SystemInitializerFull
Summary:
This plugin resembles the already existing Windows-only Minidump plugin.
The WinMinidumpPlugin uses the Windows API for parsing Minidumps
while this plugin is cross-platform because it includes a Minidump
parser (which is already commited)
It is able to produce a backtrace, to read the general puprose regiters,
inspect local variables, show image list, do memory reads, etc.
For now the only arches that this supports are x86_32 and x86_64.
This is because I have only written register contexts for those.
Others will come in next CLs.
I copied the WinMinidump tests and adapted them a little bit for them to
work with the new plugin (and they pass)
I will add more tests, aiming for better code coverage.
There is still functionality to be added, see TODOs in code.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, modocache, lldb-commits, amccarth
Differential Revision: https://reviews.llvm.org/D25905
llvm-svn: 285587
2016-10-31 15:35:18 +00:00
|
|
|
#include "Plugins/Process/minidump/ProcessMinidump.h"
|
2015-07-30 20:28:07 +00:00
|
|
|
#include "Plugins/ScriptInterpreter/None/ScriptInterpreterNone.h"
|
Introduce SymbolFileBreakpad and use it to fill symtab
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
2019-01-11 11:17:51 +00:00
|
|
|
#include "Plugins/SymbolFile/Breakpad/SymbolFileBreakpad.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
#include "Plugins/SymbolFile/DWARF/SymbolFileDWARF.h"
|
|
|
|
|
#include "Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h"
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
#include "Plugins/SymbolFile/PDB/SymbolFilePDB.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
#include "Plugins/SymbolFile/Symtab/SymbolFileSymtab.h"
|
|
|
|
|
#include "Plugins/SymbolVendor/ELF/SymbolVendorELF.h"
|
2020-01-16 08:36:45 -08:00
|
|
|
#include "Plugins/SymbolVendor/wasm/SymbolVendorWasm.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
#include "Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.h"
|
|
|
|
|
#include "Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.h"
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
#include "Plugins/UnwindAssembly/x86/UnwindAssembly-x86.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
|
|
|
|
|
#if defined(__APPLE__)
|
2016-06-29 13:58:27 +00:00
|
|
|
#include "Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.h"
|
|
|
|
|
#include "Plugins/Process/MacOSX-Kernel/ProcessKDP.h"
|
|
|
|
|
#include "Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
#endif
|
2016-08-19 04:21:48 +00:00
|
|
|
#include "Plugins/StructuredData/DarwinLog/StructuredDataDarwinLog.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
|
|
|
|
|
#if defined(__FreeBSD__)
|
|
|
|
|
#include "Plugins/Process/FreeBSD/ProcessFreeBSD.h"
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-12-15 15:00:41 +00:00
|
|
|
#if defined(_WIN32)
|
2016-11-23 16:26:37 +00:00
|
|
|
#include "Plugins/Process/Windows/Common/ProcessWindows.h"
|
2015-03-31 21:03:22 +00:00
|
|
|
#include "lldb/Host/windows/windows.h"
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#include "llvm/Support/TargetSelect.h"
|
|
|
|
|
|
2019-05-03 23:19:27 +00:00
|
|
|
#pragma clang diagnostic push
|
|
|
|
|
#pragma clang diagnostic ignored "-Wglobal-constructors"
|
|
|
|
|
#include "llvm/ExecutionEngine/MCJIT.h"
|
|
|
|
|
#pragma clang diagnostic pop
|
|
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
#include <string>
|
|
|
|
|
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
|
|
SystemInitializerFull::SystemInitializerFull() {}
|
|
|
|
|
|
|
|
|
|
SystemInitializerFull::~SystemInitializerFull() {}
|
|
|
|
|
|
2019-09-26 09:47:32 +00:00
|
|
|
#define LLDB_PROCESS_AArch64(op) \
|
|
|
|
|
ABIMacOSX_arm64::op(); \
|
|
|
|
|
ABISysV_arm64::op();
|
|
|
|
|
#define LLDB_PROCESS_ARM(op) \
|
|
|
|
|
ABIMacOSX_arm::op(); \
|
|
|
|
|
ABISysV_arm::op();
|
2019-10-17 15:18:03 +00:00
|
|
|
#define LLDB_PROCESS_ARC(op) \
|
|
|
|
|
ABISysV_arc::op();
|
2019-09-26 09:47:32 +00:00
|
|
|
#define LLDB_PROCESS_Hexagon(op) ABISysV_hexagon::op();
|
|
|
|
|
#define LLDB_PROCESS_Mips(op) \
|
|
|
|
|
ABISysV_mips::op(); \
|
|
|
|
|
ABISysV_mips64::op();
|
|
|
|
|
#define LLDB_PROCESS_PowerPC(op) \
|
|
|
|
|
ABISysV_ppc::op(); \
|
|
|
|
|
ABISysV_ppc64::op();
|
|
|
|
|
#define LLDB_PROCESS_SystemZ(op) ABISysV_s390x::op();
|
|
|
|
|
#define LLDB_PROCESS_X86(op) \
|
|
|
|
|
ABIMacOSX_i386::op(); \
|
|
|
|
|
ABISysV_i386::op(); \
|
|
|
|
|
ABISysV_x86_64::op(); \
|
|
|
|
|
ABIWindows_x86_64::op();
|
|
|
|
|
|
|
|
|
|
#define LLDB_PROCESS_AMDGPU(op)
|
2019-09-26 17:15:18 +00:00
|
|
|
#define LLDB_PROCESS_AVR(op)
|
2019-09-26 09:47:32 +00:00
|
|
|
#define LLDB_PROCESS_BPF(op)
|
|
|
|
|
#define LLDB_PROCESS_Lanai(op)
|
|
|
|
|
#define LLDB_PROCESS_MSP430(op)
|
|
|
|
|
#define LLDB_PROCESS_NVPTX(op)
|
|
|
|
|
#define LLDB_PROCESS_RISCV(op)
|
|
|
|
|
#define LLDB_PROCESS_Sparc(op)
|
|
|
|
|
#define LLDB_PROCESS_WebAssembly(op)
|
|
|
|
|
#define LLDB_PROCESS_XCore(op)
|
|
|
|
|
|
2019-02-21 22:26:16 +00:00
|
|
|
llvm::Error SystemInitializerFull::Initialize() {
|
|
|
|
|
if (auto e = SystemInitializerCommon::Initialize())
|
2018-12-03 17:28:29 +00:00
|
|
|
return e;
|
2018-05-24 12:44:18 +00:00
|
|
|
|
Re-commit "Introduce ObjectFileBreakpad"
This re-commits r348592, which was reverted due to a failing test on
macos.
The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).
It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.
The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348773
2018-12-10 17:16:38 +00:00
|
|
|
breakpad::ObjectFileBreakpad::Initialize();
|
2018-05-24 12:44:18 +00:00
|
|
|
ObjectFileELF::Initialize();
|
|
|
|
|
ObjectFileMachO::Initialize();
|
|
|
|
|
ObjectFilePECOFF::Initialize();
|
[LLDB] Add ObjectFileWasm plugin for WebAssembly debugging
Summary:
This is the first in a series of patches to enable LLDB debugging of
WebAssembly targets.
Current versions of Clang emit (partial) DWARF debug information in WebAssembly
modules and we can leverage this debug information to give LLDB the ability to
do source-level debugging of Wasm code that runs in a WebAssembly engine.
A way to do this could be to use the remote debugging functionalities provided
by LLDB via the GDB-remote protocol. Remote debugging can indeed be useful not
only to connect a debugger to a process running on a remote machine, but also to
connect the debugger to a managed VM or script engine that runs locally,
provided that the engine implements a GDB-remote stub that offers the ability to
access the engine runtime internal state.
To make this work, the GDB-remote protocol would need to be extended with a few
Wasm-specific custom query commands, used to access aspects of the Wasm engine
state (like the Wasm memory, Wasm local and global variables, and so on).
Furthermore, the DWARF format would need to be enriched with a few Wasm-specific
extensions, here detailed: https://yurydelendik.github.io/webassembly-dwarf.
This CL introduce classes **ObjectFileWasm**, a file plugin to represent a Wasm
module loaded in a debuggee process. It knows how to parse Wasm modules and
store the Code section and the DWARF-specific sections.
Reviewers: jasonmolenda, clayborg, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71575
2020-01-15 15:29:24 -08:00
|
|
|
wasm::ObjectFileWasm::Initialize();
|
2018-05-24 12:44:18 +00:00
|
|
|
|
2019-05-02 18:11:44 +00:00
|
|
|
ObjectContainerBSDArchive::Initialize();
|
|
|
|
|
ObjectContainerUniversalMachO::Initialize();
|
|
|
|
|
|
2015-08-23 09:05:29 +00:00
|
|
|
ScriptInterpreterNone::Initialize();
|
2015-07-30 20:28:07 +00:00
|
|
|
|
2019-12-13 10:37:33 -08:00
|
|
|
#if LLDB_ENABLE_PYTHON
|
2016-03-16 08:48:56 +00:00
|
|
|
OperatingSystemPython::Initialize();
|
|
|
|
|
#endif
|
|
|
|
|
|
2019-12-13 10:37:33 -08:00
|
|
|
#if LLDB_ENABLE_PYTHON
|
2015-07-30 20:28:07 +00:00
|
|
|
ScriptInterpreterPython::Initialize();
|
|
|
|
|
#endif
|
2015-03-31 21:03:22 +00:00
|
|
|
|
2019-12-07 15:49:35 -08:00
|
|
|
#if LLDB_ENABLE_LUA
|
|
|
|
|
ScriptInterpreterLua::Initialize();
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-06-29 13:58:27 +00:00
|
|
|
platform_freebsd::PlatformFreeBSD::Initialize();
|
|
|
|
|
platform_linux::PlatformLinux::Initialize();
|
|
|
|
|
platform_netbsd::PlatformNetBSD::Initialize();
|
[LLDB] OpenBSD support
Summary:
Add basic OpenBSD support. This is enough to be able to analyze core dumps for OpenBSD/amd64, OpenBSD/arm, OpenBSD/arm64 and OpenBSD/i386.
Note that part of the changes to source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp fix a bug that probably affects other platforms as well. The GetProgramHeaderByIndex() interface use 1-based indices, but in some case when looping over the headers the, the loop starts at 0 and misses the last header. This caused problems on OpenBSD since OpenBSD core dumps have the PT_NOTE segment as the last program header.
Reviewers: joerg, labath, krytarowski
Reviewed By: krytarowski
Subscribers: aemerson, emaste, rengolin, srhines, krytarowski, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31131
llvm-svn: 298810
2017-03-26 15:34:57 +00:00
|
|
|
platform_openbsd::PlatformOpenBSD::Initialize();
|
2016-06-29 13:58:27 +00:00
|
|
|
PlatformWindows::Initialize();
|
|
|
|
|
platform_android::PlatformAndroid::Initialize();
|
|
|
|
|
PlatformRemoteiOS::Initialize();
|
|
|
|
|
PlatformMacOSX::Initialize();
|
|
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
// Initialize LLVM and Clang
|
|
|
|
|
llvm::InitializeAllTargets();
|
|
|
|
|
llvm::InitializeAllAsmPrinters();
|
|
|
|
|
llvm::InitializeAllTargetMCs();
|
|
|
|
|
llvm::InitializeAllDisassemblers();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang::Initialize();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2019-09-26 09:47:32 +00:00
|
|
|
#define LLVM_TARGET(t) LLDB_PROCESS_ ## t(Initialize)
|
|
|
|
|
#include "llvm/Config/Targets.def"
|
2017-10-25 21:05:31 +00:00
|
|
|
|
|
|
|
|
ArchitectureArm::Initialize();
|
2018-12-13 14:28:25 +00:00
|
|
|
ArchitectureMips::Initialize();
|
2018-03-12 21:17:04 +00:00
|
|
|
ArchitecturePPC64::Initialize();
|
2017-10-25 21:05:31 +00:00
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
DisassemblerLLVMC::Initialize();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
JITLoaderGDB::Initialize();
|
|
|
|
|
ProcessElfCore::Initialize();
|
2018-05-22 16:33:43 +00:00
|
|
|
ProcessMachCore::Initialize();
|
Minidump plugin: Adding ProcessMinidump, ThreadMinidump and register the plugin in SystemInitializerFull
Summary:
This plugin resembles the already existing Windows-only Minidump plugin.
The WinMinidumpPlugin uses the Windows API for parsing Minidumps
while this plugin is cross-platform because it includes a Minidump
parser (which is already commited)
It is able to produce a backtrace, to read the general puprose regiters,
inspect local variables, show image list, do memory reads, etc.
For now the only arches that this supports are x86_32 and x86_64.
This is because I have only written register contexts for those.
Others will come in next CLs.
I copied the WinMinidump tests and adapted them a little bit for them to
work with the new plugin (and they pass)
I will add more tests, aiming for better code coverage.
There is still functionality to be added, see TODOs in code.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, modocache, lldb-commits, amccarth
Differential Revision: https://reviews.llvm.org/D25905
llvm-svn: 285587
2016-10-31 15:35:18 +00:00
|
|
|
minidump::ProcessMinidump::Initialize();
|
2015-03-31 21:03:22 +00:00
|
|
|
MemoryHistoryASan::Initialize();
|
2020-01-21 14:43:46 -08:00
|
|
|
InstrumentationRuntimeASan::Initialize();
|
2020-01-21 14:50:36 -08:00
|
|
|
InstrumentationRuntimeTSan::Initialize();
|
2020-01-21 14:55:13 -08:00
|
|
|
InstrumentationRuntimeUBSan::Initialize();
|
2020-01-21 15:01:36 -08:00
|
|
|
InstrumentationRuntimeMainThreadChecker::Initialize();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
SymbolVendorELF::Initialize();
|
Introduce SymbolFileBreakpad and use it to fill symtab
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
2019-01-11 11:17:51 +00:00
|
|
|
breakpad::SymbolFileBreakpad::Initialize();
|
2015-03-31 21:03:22 +00:00
|
|
|
SymbolFileDWARF::Initialize();
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
SymbolFilePDB::Initialize();
|
2015-03-31 21:03:22 +00:00
|
|
|
SymbolFileSymtab::Initialize();
|
2020-01-16 08:36:45 -08:00
|
|
|
wasm::SymbolVendorWasm::Initialize();
|
2015-03-31 21:03:22 +00:00
|
|
|
UnwindAssemblyInstEmulation::Initialize();
|
|
|
|
|
UnwindAssembly_x86::Initialize();
|
2019-05-06 19:38:24 +00:00
|
|
|
|
|
|
|
|
EmulateInstructionARM::Initialize();
|
2015-03-31 21:03:22 +00:00
|
|
|
EmulateInstructionARM64::Initialize();
|
2019-05-06 19:38:24 +00:00
|
|
|
EmulateInstructionMIPS::Initialize();
|
|
|
|
|
EmulateInstructionMIPS64::Initialize();
|
2018-02-27 18:42:46 +00:00
|
|
|
EmulateInstructionPPC64::Initialize();
|
2019-05-06 19:38:24 +00:00
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
SymbolFileDWARFDebugMap::Initialize();
|
|
|
|
|
ItaniumABILanguageRuntime::Initialize();
|
2020-01-21 22:20:48 -08:00
|
|
|
AppleObjCRuntime::Initialize();
|
2015-03-31 21:03:22 +00:00
|
|
|
SystemRuntimeMacOSX::Initialize();
|
2015-04-09 16:49:25 +00:00
|
|
|
RenderScriptRuntime::Initialize();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-09-01 18:22:39 +00:00
|
|
|
CPlusPlusLanguage::Initialize();
|
|
|
|
|
ObjCLanguage::Initialize();
|
|
|
|
|
ObjCPlusPlusLanguage::Initialize();
|
2015-03-31 21:03:22 +00:00
|
|
|
|
2016-12-15 15:00:41 +00:00
|
|
|
#if defined(_WIN32)
|
2016-11-23 16:26:37 +00:00
|
|
|
ProcessWindows::Initialize();
|
2015-03-31 21:03:22 +00:00
|
|
|
#endif
|
|
|
|
|
#if defined(__FreeBSD__)
|
|
|
|
|
ProcessFreeBSD::Initialize();
|
|
|
|
|
#endif
|
|
|
|
|
#if defined(__APPLE__)
|
|
|
|
|
SymbolVendorMacOSX::Initialize();
|
|
|
|
|
ProcessKDP::Initialize();
|
2016-03-29 15:00:26 +00:00
|
|
|
DynamicLoaderDarwinKernel::Initialize();
|
2015-03-31 21:03:22 +00:00
|
|
|
#endif
|
2016-08-19 04:21:48 +00:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// This plugin is valid on any host that talks to a Darwin remote. It
|
|
|
|
|
// shouldn't be limited to __APPLE__.
|
2016-08-19 04:21:48 +00:00
|
|
|
StructuredDataDarwinLog::Initialize();
|
|
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
// Platform agnostic plugins
|
|
|
|
|
platform_gdb_server::PlatformRemoteGDBServer::Initialize();
|
|
|
|
|
|
|
|
|
|
process_gdb_remote::ProcessGDBRemote::Initialize();
|
2016-03-29 15:00:26 +00:00
|
|
|
DynamicLoaderMacOSXDYLD::Initialize();
|
2016-07-21 08:30:55 +00:00
|
|
|
DynamicLoaderMacOS::Initialize();
|
2016-03-29 15:00:26 +00:00
|
|
|
DynamicLoaderPOSIXDYLD::Initialize();
|
2015-03-31 21:03:22 +00:00
|
|
|
DynamicLoaderStatic::Initialize();
|
2016-03-29 15:00:26 +00:00
|
|
|
DynamicLoaderWindowsDYLD::Initialize();
|
2015-03-31 21:03:22 +00:00
|
|
|
|
|
|
|
|
// Scan for any system or user LLDB plug-ins
|
|
|
|
|
PluginManager::Initialize();
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// The process settings need to know about installed plug-ins, so the
|
|
|
|
|
// Settings must be initialized
|
2015-03-31 21:03:22 +00:00
|
|
|
// AFTER PluginManager::Initialize is called.
|
|
|
|
|
|
|
|
|
|
Debugger::SettingsInitialize();
|
2018-12-03 17:28:29 +00:00
|
|
|
|
|
|
|
|
return llvm::Error::success();
|
2015-03-31 21:03:22 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SystemInitializerFull::Terminate() {
|
2017-05-15 13:02:37 +00:00
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
|
|
|
|
Timer scoped_timer(func_cat, LLVM_PRETTY_FUNCTION);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
Debugger::SettingsTerminate();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
// Terminate and unload and loaded system or user LLDB plug-ins
|
|
|
|
|
PluginManager::Terminate();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang::Terminate();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-12-13 14:28:25 +00:00
|
|
|
ArchitectureArm::Terminate();
|
|
|
|
|
ArchitectureMips::Terminate();
|
|
|
|
|
ArchitecturePPC64::Terminate();
|
|
|
|
|
|
2019-09-26 09:47:32 +00:00
|
|
|
#define LLVM_TARGET(t) LLDB_PROCESS_ ## t(Terminate)
|
|
|
|
|
#include "llvm/Config/Targets.def"
|
Have ABI plugins vend llvm MCRegisterInfo data
Summary:
I was recently surprised to learn that there is a total of 2 (two) users
of the register info definitions contained in the ABI plugins. Yet, the
defitions themselves span nearly 10kLOC.
The two users are:
- dwarf expression pretty printer
- the mechanism for augmenting the register info definitions obtained
over gdb-remote protocol (AugmentRegisterInfoViaABI)
Both of these uses need the DWARF an EH register numbers, which is
information that is already available in LLVM. This patch makes it
possible to do so.
It adds a GetMCRegisterInfo method to the ABI class, which every class
is expected to implement. Normally, it should be sufficient to obtain
the definitions from the appropriate llvm::Target object (for which I
provide a utility function), but the subclasses are free to construct it
in any way they deem fit.
We should be able to always get the MCRegisterInfo object from llvm,
with one important exception: if the relevant llvm target was disabled
at compile time. To handle this, I add a mechanism to disable the
compilation of ABI plugins based on the value of LLVM_TARGETS_TO_BUILD
cmake setting. This ensures all our existing are able to create their
MCRegisterInfo objects.
The new MCRegisterInfo api is not used yet, but the intention is to make
use of it in follow-up patches.
Reviewers: jasonmolenda, aprantl, JDevlieghere, tatyana-krasnukha
Subscribers: wuzish, nemanjai, mgorny, kbarton, atanasyan, lldb-commits
Differential Revision: https://reviews.llvm.org/D67965
llvm-svn: 372862
2019-09-25 13:03:04 +00:00
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
DisassemblerLLVMC::Terminate();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
JITLoaderGDB::Terminate();
|
|
|
|
|
ProcessElfCore::Terminate();
|
2018-05-22 16:33:43 +00:00
|
|
|
ProcessMachCore::Terminate();
|
Minidump plugin: Adding ProcessMinidump, ThreadMinidump and register the plugin in SystemInitializerFull
Summary:
This plugin resembles the already existing Windows-only Minidump plugin.
The WinMinidumpPlugin uses the Windows API for parsing Minidumps
while this plugin is cross-platform because it includes a Minidump
parser (which is already commited)
It is able to produce a backtrace, to read the general puprose regiters,
inspect local variables, show image list, do memory reads, etc.
For now the only arches that this supports are x86_32 and x86_64.
This is because I have only written register contexts for those.
Others will come in next CLs.
I copied the WinMinidump tests and adapted them a little bit for them to
work with the new plugin (and they pass)
I will add more tests, aiming for better code coverage.
There is still functionality to be added, see TODOs in code.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, modocache, lldb-commits, amccarth
Differential Revision: https://reviews.llvm.org/D25905
llvm-svn: 285587
2016-10-31 15:35:18 +00:00
|
|
|
minidump::ProcessMinidump::Terminate();
|
2015-03-31 21:03:22 +00:00
|
|
|
MemoryHistoryASan::Terminate();
|
2020-01-21 14:43:46 -08:00
|
|
|
InstrumentationRuntimeASan::Terminate();
|
2020-01-21 14:50:36 -08:00
|
|
|
InstrumentationRuntimeTSan::Terminate();
|
2020-01-21 14:55:13 -08:00
|
|
|
InstrumentationRuntimeUBSan::Terminate();
|
2020-01-21 15:01:36 -08:00
|
|
|
InstrumentationRuntimeMainThreadChecker::Terminate();
|
|
|
|
|
|
2020-01-16 08:36:45 -08:00
|
|
|
wasm::SymbolVendorWasm::Terminate();
|
2015-03-31 21:03:22 +00:00
|
|
|
SymbolVendorELF::Terminate();
|
Introduce SymbolFileBreakpad and use it to fill symtab
Summary:
This commit adds the glue code necessary to integrate the
SymbolFileBreakpad into the plugin system. Most of the methods are
stubbed out. The only method implemented method is AddSymbols, which
parses the PUBLIC "section" of the breakpad "object file", and fills out
the Module's symtab.
To enable testing this, I've made two additional changes:
- dump Symtab from the SymbolVendor class. The symtab was already being
dumped as a part of the object file dump, but that happened before
symbol vendor kicked in, so it did not reflect any symbols added
there.
- add ability to explicitly specify the external symbol file in
lldb-test (so that the object file could be linked with the breakpad
symbol file). To make things simpler, I've changed lldb-test from
consuming multiple inputs (and dumping their symbols) to having it
just process a single file per invocation. This was not a problem
since everyone was using it that way already.
Reviewers: clayborg, zturner, lemo, markmentovai, amccarth
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56173
llvm-svn: 350924
2019-01-11 11:17:51 +00:00
|
|
|
breakpad::SymbolFileBreakpad::Terminate();
|
2015-03-31 21:03:22 +00:00
|
|
|
SymbolFileDWARF::Terminate();
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
SymbolFilePDB::Terminate();
|
2015-03-31 21:03:22 +00:00
|
|
|
SymbolFileSymtab::Terminate();
|
|
|
|
|
UnwindAssembly_x86::Terminate();
|
|
|
|
|
UnwindAssemblyInstEmulation::Terminate();
|
2019-05-06 19:38:24 +00:00
|
|
|
|
|
|
|
|
EmulateInstructionARM::Terminate();
|
2015-03-31 21:03:22 +00:00
|
|
|
EmulateInstructionARM64::Terminate();
|
2019-05-06 19:38:24 +00:00
|
|
|
EmulateInstructionMIPS::Terminate();
|
|
|
|
|
EmulateInstructionMIPS64::Terminate();
|
2018-02-27 18:42:46 +00:00
|
|
|
EmulateInstructionPPC64::Terminate();
|
2019-05-06 19:38:24 +00:00
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
SymbolFileDWARFDebugMap::Terminate();
|
|
|
|
|
ItaniumABILanguageRuntime::Terminate();
|
2020-01-21 22:20:48 -08:00
|
|
|
AppleObjCRuntime::Terminate();
|
2015-03-31 21:03:22 +00:00
|
|
|
SystemRuntimeMacOSX::Terminate();
|
2015-04-09 16:49:25 +00:00
|
|
|
RenderScriptRuntime::Terminate();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2015-09-01 18:22:39 +00:00
|
|
|
CPlusPlusLanguage::Terminate();
|
|
|
|
|
ObjCLanguage::Terminate();
|
|
|
|
|
ObjCPlusPlusLanguage::Terminate();
|
2016-01-04 01:43:47 +00:00
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
#if defined(__APPLE__)
|
2016-03-29 15:00:26 +00:00
|
|
|
DynamicLoaderDarwinKernel::Terminate();
|
2015-03-31 21:03:22 +00:00
|
|
|
ProcessKDP::Terminate();
|
|
|
|
|
SymbolVendorMacOSX::Terminate();
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if defined(__FreeBSD__)
|
|
|
|
|
ProcessFreeBSD::Terminate();
|
|
|
|
|
#endif
|
|
|
|
|
Debugger::SettingsTerminate();
|
|
|
|
|
|
|
|
|
|
platform_gdb_server::PlatformRemoteGDBServer::Terminate();
|
|
|
|
|
process_gdb_remote::ProcessGDBRemote::Terminate();
|
2016-08-19 04:21:48 +00:00
|
|
|
StructuredDataDarwinLog::Terminate();
|
|
|
|
|
|
2016-03-29 15:00:26 +00:00
|
|
|
DynamicLoaderMacOSXDYLD::Terminate();
|
2016-07-21 08:30:55 +00:00
|
|
|
DynamicLoaderMacOS::Terminate();
|
2016-03-29 15:00:26 +00:00
|
|
|
DynamicLoaderPOSIXDYLD::Terminate();
|
2015-03-31 21:03:22 +00:00
|
|
|
DynamicLoaderStatic::Terminate();
|
2016-03-29 15:00:26 +00:00
|
|
|
DynamicLoaderWindowsDYLD::Terminate();
|
2015-03-31 21:03:22 +00:00
|
|
|
|
2016-06-29 13:58:27 +00:00
|
|
|
platform_freebsd::PlatformFreeBSD::Terminate();
|
|
|
|
|
platform_linux::PlatformLinux::Terminate();
|
|
|
|
|
platform_netbsd::PlatformNetBSD::Terminate();
|
[LLDB] OpenBSD support
Summary:
Add basic OpenBSD support. This is enough to be able to analyze core dumps for OpenBSD/amd64, OpenBSD/arm, OpenBSD/arm64 and OpenBSD/i386.
Note that part of the changes to source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp fix a bug that probably affects other platforms as well. The GetProgramHeaderByIndex() interface use 1-based indices, but in some case when looping over the headers the, the loop starts at 0 and misses the last header. This caused problems on OpenBSD since OpenBSD core dumps have the PT_NOTE segment as the last program header.
Reviewers: joerg, labath, krytarowski
Reviewed By: krytarowski
Subscribers: aemerson, emaste, rengolin, srhines, krytarowski, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31131
llvm-svn: 298810
2017-03-26 15:34:57 +00:00
|
|
|
platform_openbsd::PlatformOpenBSD::Terminate();
|
2016-06-29 13:58:27 +00:00
|
|
|
PlatformWindows::Terminate();
|
|
|
|
|
platform_android::PlatformAndroid::Terminate();
|
|
|
|
|
PlatformMacOSX::Terminate();
|
|
|
|
|
PlatformRemoteiOS::Terminate();
|
|
|
|
|
|
Re-commit "Introduce ObjectFileBreakpad"
This re-commits r348592, which was reverted due to a failing test on
macos.
The issue was that I was passing a null pointer for the
"CreateMemoryInstance" callback when registering ObjectFileBreakpad,
which caused crashes when attemping to load modules from memory. The
correct thing to do is to pass a callback which always returns a null
pointer (as breakpad files are never loaded in inferior memory).
It turns out that there is only one test which exercises this code path,
and it's mac-only, so I've create a new test which should run everywhere
(except windows, as one cannot delete an executable which is being run).
Unfortunately, this test still fails on linux for other reasons, but at
least it gives us something to aim for.
The original commit message was:
This patch adds the scaffolding necessary for lldb to recognise symbol
files generated by breakpad. These (textual) files contain just enough
information to be able to produce a backtrace from a crash
dump. This information includes:
- UUID, architecture and name of the module
- line tables
- list of symbols
- unwind information
A minimal breakpad file could look like this:
MODULE Linux x86_64 0000000024B5D199F0F766FFFFFF5DC30 a.out
INFO CODE_ID 00000000B52499D1F0F766FFFFFF5DC3
FILE 0 /tmp/a.c
FUNC 1010 10 0 _start
1010 4 4 0
1014 5 5 0
1019 5 6 0
101e 2 7 0
PUBLIC 1010 0 _start
STACK CFI INIT 1010 10 .cfa: $rsp 8 + .ra: .cfa -8 + ^
STACK CFI 1011 $rbp: .cfa -16 + ^ .cfa: $rsp 16 +
STACK CFI 1014 .cfa: $rbp 16 +
Even though this data would normally be considered "symbol" information,
in the current lldb infrastructure it is assumed every SymbolFile object
is backed by an ObjectFile instance. So, in order to better interoperate
with the rest of the code (particularly symbol vendors).
In this patch I just parse the breakpad header, which is enough to
populate the UUID and architecture fields of the ObjectFile interface.
The rough plan for followup patches is to expose the individual parts of
the breakpad file as ObjectFile "sections", which can then be used by
other parts of the codebase (SymbolFileBreakpad ?) to vend the necessary
information.
Reviewers: clayborg, zturner, lemo, amccarth
Subscribers: mgorny, fedor.sergeev, markmentovai, lldb-commits
Differential Revision: https://reviews.llvm.org/D55214
llvm-svn: 348773
2018-12-10 17:16:38 +00:00
|
|
|
breakpad::ObjectFileBreakpad::Terminate();
|
2018-05-24 12:44:18 +00:00
|
|
|
ObjectFileELF::Terminate();
|
|
|
|
|
ObjectFileMachO::Terminate();
|
|
|
|
|
ObjectFilePECOFF::Terminate();
|
[LLDB] Add ObjectFileWasm plugin for WebAssembly debugging
Summary:
This is the first in a series of patches to enable LLDB debugging of
WebAssembly targets.
Current versions of Clang emit (partial) DWARF debug information in WebAssembly
modules and we can leverage this debug information to give LLDB the ability to
do source-level debugging of Wasm code that runs in a WebAssembly engine.
A way to do this could be to use the remote debugging functionalities provided
by LLDB via the GDB-remote protocol. Remote debugging can indeed be useful not
only to connect a debugger to a process running on a remote machine, but also to
connect the debugger to a managed VM or script engine that runs locally,
provided that the engine implements a GDB-remote stub that offers the ability to
access the engine runtime internal state.
To make this work, the GDB-remote protocol would need to be extended with a few
Wasm-specific custom query commands, used to access aspects of the Wasm engine
state (like the Wasm memory, Wasm local and global variables, and so on).
Furthermore, the DWARF format would need to be enriched with a few Wasm-specific
extensions, here detailed: https://yurydelendik.github.io/webassembly-dwarf.
This CL introduce classes **ObjectFileWasm**, a file plugin to represent a Wasm
module loaded in a debuggee process. It knows how to parse Wasm modules and
store the Code section and the DWARF-specific sections.
Reviewers: jasonmolenda, clayborg, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71575
2020-01-15 15:29:24 -08:00
|
|
|
wasm::ObjectFileWasm::Terminate();
|
2018-05-24 12:44:18 +00:00
|
|
|
|
2019-05-02 18:11:44 +00:00
|
|
|
ObjectContainerBSDArchive::Terminate();
|
|
|
|
|
ObjectContainerUniversalMachO::Terminate();
|
|
|
|
|
|
2020-01-17 12:31:15 +01:00
|
|
|
#if LLDB_ENABLE_PYTHON
|
|
|
|
|
OperatingSystemPython::Terminate();
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if LLDB_ENABLE_PYTHON
|
|
|
|
|
ScriptInterpreterPython::Terminate();
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if LLDB_ENABLE_LUA
|
|
|
|
|
ScriptInterpreterLua::Terminate();
|
|
|
|
|
#endif
|
|
|
|
|
|
2015-03-31 21:03:22 +00:00
|
|
|
// Now shutdown the common parts, in reverse order.
|
|
|
|
|
SystemInitializerCommon::Terminate();
|
|
|
|
|
}
|