2017-12-01 00:52:51 +00:00
|
|
|
//===-- SystemInitializerTest.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
|
2017-12-01 00:52:51 +00:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#include "SystemInitializerTest.h"
|
|
|
|
|
|
|
|
|
|
#include "lldb/Core/Debugger.h"
|
|
|
|
|
#include "lldb/Host/Host.h"
|
|
|
|
|
#include "lldb/Initialization/SystemInitializerCommon.h"
|
|
|
|
|
#include "lldb/Interpreter/CommandInterpreter.h"
|
|
|
|
|
#include "lldb/Symbol/ClangASTContext.h"
|
|
|
|
|
#include "lldb/Utility/Timer.h"
|
|
|
|
|
|
|
|
|
|
#include "Plugins/ABI/MacOSX-arm/ABIMacOSX_arm.h"
|
|
|
|
|
#include "Plugins/ABI/MacOSX-arm64/ABIMacOSX_arm64.h"
|
|
|
|
|
#include "Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.h"
|
|
|
|
|
#include "Plugins/ABI/SysV-arm/ABISysV_arm.h"
|
|
|
|
|
#include "Plugins/ABI/SysV-arm64/ABISysV_arm64.h"
|
|
|
|
|
#include "Plugins/ABI/SysV-hexagon/ABISysV_hexagon.h"
|
|
|
|
|
#include "Plugins/ABI/SysV-i386/ABISysV_i386.h"
|
|
|
|
|
#include "Plugins/ABI/SysV-mips/ABISysV_mips.h"
|
|
|
|
|
#include "Plugins/ABI/SysV-mips64/ABISysV_mips64.h"
|
|
|
|
|
#include "Plugins/ABI/SysV-ppc/ABISysV_ppc.h"
|
|
|
|
|
#include "Plugins/ABI/SysV-ppc64/ABISysV_ppc64.h"
|
|
|
|
|
#include "Plugins/ABI/SysV-s390x/ABISysV_s390x.h"
|
|
|
|
|
#include "Plugins/ABI/SysV-x86_64/ABISysV_x86_64.h"
|
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
|
|
|
#include "Plugins/ABI/Windows-x86_64/ABIWindows_x86_64.h"
|
2017-12-01 00:52:51 +00:00
|
|
|
#include "Plugins/Architecture/Arm/ArchitectureArm.h"
|
2018-03-12 21:17:04 +00:00
|
|
|
#include "Plugins/Architecture/PPC64/ArchitecturePPC64.h"
|
2017-12-01 00:52:51 +00:00
|
|
|
#include "Plugins/Disassembler/llvm/DisassemblerLLVMC.h"
|
|
|
|
|
#include "Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOS.h"
|
|
|
|
|
#include "Plugins/DynamicLoader/MacOSX-DYLD/DynamicLoaderMacOSXDYLD.h"
|
|
|
|
|
#include "Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.h"
|
|
|
|
|
#include "Plugins/DynamicLoader/Static/DynamicLoaderStatic.h"
|
|
|
|
|
#include "Plugins/DynamicLoader/Windows-DYLD/DynamicLoaderWindowsDYLD.h"
|
|
|
|
|
#include "Plugins/Instruction/ARM64/EmulateInstructionARM64.h"
|
2018-02-27 18:42:46 +00:00
|
|
|
#include "Plugins/Instruction/PPC64/EmulateInstructionPPC64.h"
|
2017-12-01 00:52:51 +00:00
|
|
|
#include "Plugins/InstrumentationRuntime/ASan/ASanRuntime.h"
|
|
|
|
|
#include "Plugins/InstrumentationRuntime/MainThreadChecker/MainThreadCheckerRuntime.h"
|
|
|
|
|
#include "Plugins/InstrumentationRuntime/TSan/TSanRuntime.h"
|
|
|
|
|
#include "Plugins/InstrumentationRuntime/UBSan/UBSanRuntime.h"
|
|
|
|
|
#include "Plugins/JITLoader/GDB/JITLoaderGDB.h"
|
|
|
|
|
#include "Plugins/Language/CPlusPlus/CPlusPlusLanguage.h"
|
|
|
|
|
#include "Plugins/Language/ObjC/ObjCLanguage.h"
|
|
|
|
|
#include "Plugins/Language/ObjCPlusPlus/ObjCPlusPlusLanguage.h"
|
|
|
|
|
#include "Plugins/LanguageRuntime/CPlusPlus/ItaniumABI/ItaniumABILanguageRuntime.h"
|
|
|
|
|
#include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV1.h"
|
|
|
|
|
#include "Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCRuntimeV2.h"
|
|
|
|
|
#include "Plugins/LanguageRuntime/RenderScript/RenderScriptRuntime/RenderScriptRuntime.h"
|
|
|
|
|
#include "Plugins/MemoryHistory/asan/MemoryHistoryASan.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"
|
2017-12-01 00:52:51 +00:00
|
|
|
#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"
|
|
|
|
|
#include "Plugins/Platform/OpenBSD/PlatformOpenBSD.h"
|
|
|
|
|
#include "Plugins/Platform/Windows/PlatformWindows.h"
|
|
|
|
|
#include "Plugins/Platform/gdb-server/PlatformRemoteGDBServer.h"
|
|
|
|
|
#include "Plugins/Process/elf-core/ProcessElfCore.h"
|
|
|
|
|
#include "Plugins/Process/gdb-remote/ProcessGDBRemote.h"
|
|
|
|
|
#include "Plugins/Process/minidump/ProcessMinidump.h"
|
|
|
|
|
#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"
|
2017-12-01 00:52:51 +00:00
|
|
|
#include "Plugins/SymbolFile/DWARF/SymbolFileDWARF.h"
|
|
|
|
|
#include "Plugins/SymbolFile/DWARF/SymbolFileDWARFDebugMap.h"
|
|
|
|
|
#include "Plugins/SymbolFile/PDB/SymbolFilePDB.h"
|
|
|
|
|
#include "Plugins/SymbolFile/Symtab/SymbolFileSymtab.h"
|
|
|
|
|
#include "Plugins/SymbolVendor/ELF/SymbolVendorELF.h"
|
|
|
|
|
#include "Plugins/SystemRuntime/MacOSX/SystemRuntimeMacOSX.h"
|
|
|
|
|
#include "Plugins/UnwindAssembly/InstEmulation/UnwindAssemblyInstEmulation.h"
|
|
|
|
|
#include "Plugins/UnwindAssembly/x86/UnwindAssembly-x86.h"
|
|
|
|
|
|
|
|
|
|
#if defined(__APPLE__)
|
|
|
|
|
#include "Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.h"
|
|
|
|
|
#include "Plugins/Platform/MacOSX/PlatformAppleTVSimulator.h"
|
|
|
|
|
#include "Plugins/Platform/MacOSX/PlatformAppleWatchSimulator.h"
|
|
|
|
|
#include "Plugins/Platform/MacOSX/PlatformDarwinKernel.h"
|
|
|
|
|
#include "Plugins/Platform/MacOSX/PlatformRemoteAppleTV.h"
|
|
|
|
|
#include "Plugins/Platform/MacOSX/PlatformRemoteAppleWatch.h"
|
|
|
|
|
#include "Plugins/Platform/MacOSX/PlatformiOSSimulator.h"
|
|
|
|
|
#include "Plugins/Process/MacOSX-Kernel/ProcessKDP.h"
|
|
|
|
|
#include "Plugins/Process/mach-core/ProcessMachCore.h"
|
|
|
|
|
#include "Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.h"
|
|
|
|
|
#endif
|
|
|
|
|
#include "Plugins/StructuredData/DarwinLog/StructuredDataDarwinLog.h"
|
|
|
|
|
|
|
|
|
|
#if defined(__FreeBSD__)
|
|
|
|
|
#include "Plugins/Process/FreeBSD/ProcessFreeBSD.h"
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if defined(_WIN32)
|
|
|
|
|
#include "Plugins/Process/Windows/Common/ProcessWindows.h"
|
|
|
|
|
#include "lldb/Host/windows/windows.h"
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#include "llvm/Support/TargetSelect.h"
|
|
|
|
|
|
|
|
|
|
#include <string>
|
|
|
|
|
|
|
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
|
|
SystemInitializerTest::SystemInitializerTest() {}
|
|
|
|
|
|
|
|
|
|
SystemInitializerTest::~SystemInitializerTest() {}
|
|
|
|
|
|
2019-02-21 22:26:16 +00:00
|
|
|
llvm::Error SystemInitializerTest::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();
|
|
|
|
|
|
2017-12-01 00:52:51 +00:00
|
|
|
ScriptInterpreterNone::Initialize();
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
platform_freebsd::PlatformFreeBSD::Initialize();
|
|
|
|
|
platform_linux::PlatformLinux::Initialize();
|
|
|
|
|
platform_netbsd::PlatformNetBSD::Initialize();
|
|
|
|
|
platform_openbsd::PlatformOpenBSD::Initialize();
|
|
|
|
|
PlatformWindows::Initialize();
|
|
|
|
|
platform_android::PlatformAndroid::Initialize();
|
|
|
|
|
PlatformRemoteiOS::Initialize();
|
|
|
|
|
PlatformMacOSX::Initialize();
|
|
|
|
|
#if defined(__APPLE__)
|
|
|
|
|
PlatformiOSSimulator::Initialize();
|
|
|
|
|
PlatformDarwinKernel::Initialize();
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
// Initialize LLVM and Clang
|
|
|
|
|
llvm::InitializeAllTargets();
|
|
|
|
|
llvm::InitializeAllAsmPrinters();
|
|
|
|
|
llvm::InitializeAllTargetMCs();
|
|
|
|
|
llvm::InitializeAllDisassemblers();
|
|
|
|
|
|
|
|
|
|
ClangASTContext::Initialize();
|
|
|
|
|
|
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
|
|
|
#ifdef LLVM_TARGET_AArch64_BUILT
|
2017-12-01 00:52:51 +00:00
|
|
|
ABIMacOSX_arm64::Initialize();
|
|
|
|
|
ABISysV_arm64::Initialize();
|
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
|
|
|
#endif
|
|
|
|
|
#ifdef LLVM_TARGET_ARM_BUILT
|
|
|
|
|
ABIMacOSX_arm::Initialize();
|
|
|
|
|
ABISysV_arm::Initialize();
|
|
|
|
|
#endif
|
|
|
|
|
#ifdef LLVM_TARGET_Hexagon_BUILT
|
2017-12-01 00:52:51 +00:00
|
|
|
ABISysV_hexagon::Initialize();
|
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
|
|
|
#endif
|
|
|
|
|
#ifdef LLVM_TARGET_Mips_BUILT
|
2017-12-01 00:52:51 +00:00
|
|
|
ABISysV_mips::Initialize();
|
|
|
|
|
ABISysV_mips64::Initialize();
|
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
|
|
|
#endif
|
|
|
|
|
#ifdef LLVM_TARGET_PowerPC_BUILT
|
|
|
|
|
ABISysV_ppc::Initialize();
|
|
|
|
|
ABISysV_ppc64::Initialize();
|
|
|
|
|
#endif
|
|
|
|
|
#ifdef LLVM_TARGET_SystemZ_BUILT
|
2017-12-01 00:52:51 +00:00
|
|
|
ABISysV_s390x::Initialize();
|
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
|
|
|
#endif
|
|
|
|
|
#ifdef LLVM_TARGET_X86_BUILT
|
|
|
|
|
ABIMacOSX_i386::Initialize();
|
|
|
|
|
ABISysV_i386::Initialize();
|
|
|
|
|
ABISysV_x86_64::Initialize();
|
|
|
|
|
ABIWindows_x86_64::Initialize();
|
|
|
|
|
#endif
|
2017-12-01 00:52:51 +00:00
|
|
|
|
|
|
|
|
ArchitectureArm::Initialize();
|
2018-03-12 21:17:04 +00:00
|
|
|
ArchitecturePPC64::Initialize();
|
2017-12-01 00:52:51 +00:00
|
|
|
|
|
|
|
|
DisassemblerLLVMC::Initialize();
|
|
|
|
|
|
|
|
|
|
JITLoaderGDB::Initialize();
|
|
|
|
|
ProcessElfCore::Initialize();
|
|
|
|
|
minidump::ProcessMinidump::Initialize();
|
|
|
|
|
MemoryHistoryASan::Initialize();
|
|
|
|
|
AddressSanitizerRuntime::Initialize();
|
|
|
|
|
ThreadSanitizerRuntime::Initialize();
|
|
|
|
|
UndefinedBehaviorSanitizerRuntime::Initialize();
|
|
|
|
|
MainThreadCheckerRuntime::Initialize();
|
|
|
|
|
|
|
|
|
|
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();
|
2017-12-01 00:52:51 +00:00
|
|
|
SymbolFileDWARF::Initialize();
|
|
|
|
|
SymbolFilePDB::Initialize();
|
|
|
|
|
SymbolFileSymtab::Initialize();
|
|
|
|
|
UnwindAssemblyInstEmulation::Initialize();
|
|
|
|
|
UnwindAssembly_x86::Initialize();
|
|
|
|
|
EmulateInstructionARM64::Initialize();
|
2018-02-27 18:42:46 +00:00
|
|
|
EmulateInstructionPPC64::Initialize();
|
2017-12-01 00:52:51 +00:00
|
|
|
SymbolFileDWARFDebugMap::Initialize();
|
|
|
|
|
ItaniumABILanguageRuntime::Initialize();
|
|
|
|
|
AppleObjCRuntimeV2::Initialize();
|
|
|
|
|
AppleObjCRuntimeV1::Initialize();
|
|
|
|
|
SystemRuntimeMacOSX::Initialize();
|
|
|
|
|
RenderScriptRuntime::Initialize();
|
|
|
|
|
|
|
|
|
|
CPlusPlusLanguage::Initialize();
|
|
|
|
|
ObjCLanguage::Initialize();
|
|
|
|
|
ObjCPlusPlusLanguage::Initialize();
|
|
|
|
|
|
|
|
|
|
#if defined(_WIN32)
|
|
|
|
|
ProcessWindows::Initialize();
|
|
|
|
|
#endif
|
|
|
|
|
#if defined(__FreeBSD__)
|
|
|
|
|
ProcessFreeBSD::Initialize();
|
|
|
|
|
#endif
|
|
|
|
|
#if defined(__APPLE__)
|
|
|
|
|
SymbolVendorMacOSX::Initialize();
|
|
|
|
|
ProcessKDP::Initialize();
|
|
|
|
|
ProcessMachCore::Initialize();
|
|
|
|
|
PlatformAppleTVSimulator::Initialize();
|
|
|
|
|
PlatformAppleWatchSimulator::Initialize();
|
|
|
|
|
PlatformRemoteAppleTV::Initialize();
|
|
|
|
|
PlatformRemoteAppleWatch::Initialize();
|
|
|
|
|
DynamicLoaderDarwinKernel::Initialize();
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
// This plugin is valid on any host that talks to a Darwin remote.
|
|
|
|
|
// It shouldn't be limited to __APPLE__.
|
|
|
|
|
StructuredDataDarwinLog::Initialize();
|
|
|
|
|
|
|
|
|
|
// Platform agnostic plugins
|
|
|
|
|
platform_gdb_server::PlatformRemoteGDBServer::Initialize();
|
|
|
|
|
|
|
|
|
|
process_gdb_remote::ProcessGDBRemote::Initialize();
|
|
|
|
|
DynamicLoaderMacOSXDYLD::Initialize();
|
|
|
|
|
DynamicLoaderMacOS::Initialize();
|
|
|
|
|
DynamicLoaderPOSIXDYLD::Initialize();
|
|
|
|
|
DynamicLoaderStatic::Initialize();
|
|
|
|
|
DynamicLoaderWindowsDYLD::Initialize();
|
|
|
|
|
|
|
|
|
|
// Scan for any system or user LLDB plug-ins
|
|
|
|
|
PluginManager::Initialize();
|
|
|
|
|
|
|
|
|
|
// The process settings need to know about installed plug-ins, so the Settings
|
|
|
|
|
// must be initialized
|
|
|
|
|
// AFTER PluginManager::Initialize is called.
|
|
|
|
|
|
|
|
|
|
Debugger::SettingsInitialize();
|
2018-12-03 17:28:29 +00:00
|
|
|
|
|
|
|
|
return llvm::Error::success();
|
2017-12-01 00:52:51 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SystemInitializerTest::Terminate() {
|
|
|
|
|
static Timer::Category func_cat(LLVM_PRETTY_FUNCTION);
|
|
|
|
|
Timer scoped_timer(func_cat, LLVM_PRETTY_FUNCTION);
|
|
|
|
|
|
|
|
|
|
Debugger::SettingsTerminate();
|
|
|
|
|
|
|
|
|
|
// Terminate and unload and loaded system or user LLDB plug-ins
|
|
|
|
|
PluginManager::Terminate();
|
|
|
|
|
|
|
|
|
|
ClangASTContext::Terminate();
|
|
|
|
|
|
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
|
|
|
#ifdef LLVM_TARGET_AArch64_BUILT
|
2017-12-01 00:52:51 +00:00
|
|
|
ABIMacOSX_arm64::Terminate();
|
|
|
|
|
ABISysV_arm64::Terminate();
|
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
|
|
|
#endif
|
|
|
|
|
#ifdef LLVM_TARGET_ARM_BUILT
|
|
|
|
|
ABIMacOSX_arm::Terminate();
|
|
|
|
|
ABISysV_arm::Terminate();
|
|
|
|
|
#endif
|
|
|
|
|
#ifdef LLVM_TARGET_Hexagon_BUILT
|
2017-12-01 00:52:51 +00:00
|
|
|
ABISysV_hexagon::Terminate();
|
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
|
|
|
#endif
|
|
|
|
|
#ifdef LLVM_TARGET_Mips_BUILT
|
2017-12-01 00:52:51 +00:00
|
|
|
ABISysV_mips::Terminate();
|
|
|
|
|
ABISysV_mips64::Terminate();
|
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
|
|
|
#endif
|
|
|
|
|
#ifdef LLVM_TARGET_PowerPC_BUILT
|
|
|
|
|
ABISysV_ppc::Terminate();
|
|
|
|
|
ABISysV_ppc64::Terminate();
|
|
|
|
|
#endif
|
|
|
|
|
#ifdef LLVM_TARGET_SystemZ_BUILT
|
2017-12-01 00:52:51 +00:00
|
|
|
ABISysV_s390x::Terminate();
|
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
|
|
|
#endif
|
|
|
|
|
#ifdef LLVM_TARGET_X86_BUILT
|
|
|
|
|
ABIMacOSX_i386::Terminate();
|
|
|
|
|
ABISysV_i386::Terminate();
|
|
|
|
|
ABISysV_x86_64::Terminate();
|
|
|
|
|
ABIWindows_x86_64::Terminate();
|
|
|
|
|
#endif
|
|
|
|
|
|
2017-12-01 00:52:51 +00:00
|
|
|
DisassemblerLLVMC::Terminate();
|
|
|
|
|
|
|
|
|
|
JITLoaderGDB::Terminate();
|
|
|
|
|
ProcessElfCore::Terminate();
|
|
|
|
|
minidump::ProcessMinidump::Terminate();
|
|
|
|
|
MemoryHistoryASan::Terminate();
|
|
|
|
|
AddressSanitizerRuntime::Terminate();
|
|
|
|
|
ThreadSanitizerRuntime::Terminate();
|
|
|
|
|
UndefinedBehaviorSanitizerRuntime::Terminate();
|
|
|
|
|
MainThreadCheckerRuntime::Terminate();
|
|
|
|
|
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();
|
2017-12-01 00:52:51 +00:00
|
|
|
SymbolFileDWARF::Terminate();
|
|
|
|
|
SymbolFilePDB::Terminate();
|
|
|
|
|
SymbolFileSymtab::Terminate();
|
|
|
|
|
UnwindAssembly_x86::Terminate();
|
|
|
|
|
UnwindAssemblyInstEmulation::Terminate();
|
|
|
|
|
EmulateInstructionARM64::Terminate();
|
2018-02-27 18:42:46 +00:00
|
|
|
EmulateInstructionPPC64::Terminate();
|
2017-12-01 00:52:51 +00:00
|
|
|
SymbolFileDWARFDebugMap::Terminate();
|
|
|
|
|
ItaniumABILanguageRuntime::Terminate();
|
|
|
|
|
AppleObjCRuntimeV2::Terminate();
|
|
|
|
|
AppleObjCRuntimeV1::Terminate();
|
|
|
|
|
SystemRuntimeMacOSX::Terminate();
|
|
|
|
|
RenderScriptRuntime::Terminate();
|
|
|
|
|
|
|
|
|
|
CPlusPlusLanguage::Terminate();
|
|
|
|
|
ObjCLanguage::Terminate();
|
|
|
|
|
ObjCPlusPlusLanguage::Terminate();
|
|
|
|
|
|
|
|
|
|
#if defined(__APPLE__)
|
|
|
|
|
DynamicLoaderDarwinKernel::Terminate();
|
|
|
|
|
ProcessMachCore::Terminate();
|
|
|
|
|
ProcessKDP::Terminate();
|
|
|
|
|
SymbolVendorMacOSX::Terminate();
|
|
|
|
|
PlatformAppleTVSimulator::Terminate();
|
|
|
|
|
PlatformAppleWatchSimulator::Terminate();
|
|
|
|
|
PlatformRemoteAppleTV::Terminate();
|
|
|
|
|
PlatformRemoteAppleWatch::Terminate();
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if defined(__FreeBSD__)
|
|
|
|
|
ProcessFreeBSD::Terminate();
|
|
|
|
|
#endif
|
|
|
|
|
Debugger::SettingsTerminate();
|
|
|
|
|
|
|
|
|
|
platform_gdb_server::PlatformRemoteGDBServer::Terminate();
|
|
|
|
|
process_gdb_remote::ProcessGDBRemote::Terminate();
|
|
|
|
|
StructuredDataDarwinLog::Terminate();
|
|
|
|
|
|
|
|
|
|
DynamicLoaderMacOSXDYLD::Terminate();
|
|
|
|
|
DynamicLoaderMacOS::Terminate();
|
|
|
|
|
DynamicLoaderPOSIXDYLD::Terminate();
|
|
|
|
|
DynamicLoaderStatic::Terminate();
|
|
|
|
|
DynamicLoaderWindowsDYLD::Terminate();
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
platform_freebsd::PlatformFreeBSD::Terminate();
|
|
|
|
|
platform_linux::PlatformLinux::Terminate();
|
|
|
|
|
platform_netbsd::PlatformNetBSD::Terminate();
|
|
|
|
|
platform_openbsd::PlatformOpenBSD::Terminate();
|
|
|
|
|
PlatformWindows::Terminate();
|
|
|
|
|
platform_android::PlatformAndroid::Terminate();
|
|
|
|
|
PlatformMacOSX::Terminate();
|
|
|
|
|
PlatformRemoteiOS::Terminate();
|
|
|
|
|
#if defined(__APPLE__)
|
|
|
|
|
PlatformiOSSimulator::Terminate();
|
|
|
|
|
PlatformDarwinKernel::Terminate();
|
|
|
|
|
#endif
|
|
|
|
|
|
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();
|
|
|
|
|
|
2017-12-01 00:52:51 +00:00
|
|
|
// Now shutdown the common parts, in reverse order.
|
|
|
|
|
SystemInitializerCommon::Terminate();
|
|
|
|
|
}
|
