aboutsummaryrefslogtreecommitdiff
path: root/lldb/tools/lldb-test/SystemInitializerTest.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-04-08[LLDB][NFC] Remove Debugger dependency in SystemLifetimeManager (#134383)Dmitry Vasilyev1-0/+4
It reduces the memory usage in lldb-server.
2021-02-18[lldb] Fix shared library directory computation on windowsPavel Labath1-1/+2
Our code for locating the shared library directory works via dladdr (or the windows equivalent) to locate the path of an address known to reside in liblldb. This works great for C++ programs, but there's a catch. When (lib)lldb is used from python (like in our test suite), this dladdr call will return a path to the _lldb.so (or such) file in the python directory. To compensate for this, we have code which attempts to resolve this symlink, to ensure we get the canonical location. However, here's the second catch. On windows, this file is not a symlink (but a copy), so this logic fails. Since most of our other paths are derived from the liblldb location, all of these paths will be wrong, when running the test suite. One effect of this was the failure to find lldb-server in D96202. To fix this issue, I add some windows-specific code to locate the liblldb directory. Since it cannot rely on symlinks, it works by manually walking the directory tree -- essentially doing the opposite of what we do when computing the python directory. To avoid python leaking back into the host code, I implement this with the help of a callback which can be passed to HostInfo::Initialize in order to assist with the directory location. The callback lives inside the python plugin. I also strenghten the existing path test to ensure the returned path is the right one. Differential Revision: https://reviews.llvm.org/D96779
2020-12-22[lldb] Abstract scoped timer logic behind LLDB_SCOPED_TIMER (NFC)Jonas Devlieghere1-3/+0
This patch introduces a LLDB_SCOPED_TIMER macro to hide the needlessly repetitive creation of scoped timers in LLDB. It's similar to the LLDB_LOG(F) macro. Differential revision: https://reviews.llvm.org/D93663
2020-02-18Re-land "[lldb/CMake] Auto-generate the Initialize and Terminate calls for ↵Jonas Devlieghere1-202/+15
plugin" This patch changes the way we initialize and terminate the plugins in the system initializer. It uses an approach similar to LLVM's TARGETS_TO_BUILD with a def file that enumerates the plugins. Previous attempts to land this failed on the Windows bot because there's a dependency between the different process plugins. Apparently ProcessWindowsCommon needs to be initialized after all other process plugins but before ProcessGDBRemote. Differential revision: https://reviews.llvm.org/D73067
2020-02-18[lldb/Plugin] Reject WASM and Hexagon in DynamicLoaderStaticJonas Devlieghere1-3/+3
The WASM and Hexagon plugin check the ArchType rather than the OSType, so explicitly reject those in the DynamicLoaderStatic. Differential revision: https://reviews.llvm.org/D74780
2020-02-18[lldb/Plugin] Generate LLDB_PLUGIN_DECLARE with CMakeJonas Devlieghere1-78/+2
Generate the LLDB_PLUGIN_DECLARE macros with CMake and a def file. I'm landing D73067 in pieces so I can bisect what exactly is breaking the Windows bot.
2020-02-18[lldb/Plugin] Unconditionally initialize DynamicLoaderDarwinKernelJonas Devlieghere1-6/+6
Other plugins depend on DynamicLoaderDarwinKernel and which means we cannot conditionally enable/build this plugin based on the target platform. This means that it will be past of the list of plugins initialized once that's autogenerated.
2020-02-17[lldb/Plugins] Add missing initialize/terminate callsJonas Devlieghere1-0/+6
Add missing initialize and terminate calls for DynamicLoaderHexagonDYLD and ObjectFileJIT.
2020-02-17[lldb/Plugins] Rename initializers to match their plugin name.Jonas Devlieghere1-35/+35
Use LLDB_PLUGIN_DEFINE_ADV to make the name of the generated initializer match the name of the plugin. This is a step towards generating the initializers with a def file. I'm landing this change in pieces so I can narrow down what exactly breaks the Windows bot.
2020-02-17[lldb/Plugins] Initialize all ABI plugins by their plugin nameJonas Devlieghere1-11/+11
2020-02-17Revert "[lldb/CMake] Auto-generate the Initialize and Terminate calls for ↵Jonas Devlieghere1-18/+272
plugin" This is still failing spectacularly on the Windows bot and I still have no clue what's going on.
2020-02-17Re-land "[lldb/CMake] Auto-generate the Initialize and Terminate calls for ↵Jonas Devlieghere1-272/+18
plugin" This patch changes the way we initialize and terminate the plugins in the system initializer. It uses an approach similar to LLVM's TARGETS_TO_BUILD with a def file that enumerates the plugins. The previously landed patch got reverted because it was lacking: (1) A plugin definition for the Objective-C language runtime, (2) The dependency between the Static and WASM dynamic loader, (3) Explicit initialization of ScriptInterpreterNone for lldb-test. All issues have been addressed in this patch. Differential revision: https://reviews.llvm.org/D73067
2020-02-17Revert "[lldb/CMake] Auto-generate the Initialize and Terminate calls for ↵Jonas Devlieghere1-11/+275
plugin" This temporarily reverts commit 7d6da329dee1eda1761430d9097d1323f32c4c0c because it's causing test failures on the bots.
2020-02-17[lldb/CMake] Auto-generate the Initialize and Terminate calls for pluginJonas Devlieghere1-275/+11
This patch changes the way we initialize and terminate the plugins in the system initializer. It uses an approach similar to LLVM's TARGETS_TO_BUILD with a def file that enumerates the plugins. Differential revision: https://reviews.llvm.org/D73067
2020-02-17[LLDB] Add DynamicLoaderWasmDYLD plugin for WebAssembly debuggingPaolo Severini1-0/+3
Add a dynamic loader plug-in class for WebAssembly modules. Differential Revision: https://reviews.llvm.org/D72751
2020-02-13[lldb/Plugins] Have one initializer per ABI pluginJonas Devlieghere1-32/+13
After the recent change that grouped some of the ABI plugins together, those plugins ended up with multiple initializers per plugin. This is incompatible with my proposed approach of generating the initializers dynamically, which is why I've grouped them together in a new entry point. Differential revision: https://reviews.llvm.org/D74451
2020-02-12[lldb/Plugins] Move DynamicLoaderMacOS into DynamicLoaderMacOSXDYLD (NFCI)Jonas Devlieghere1-3/+0
Move the logic for initialization and termination for DynamicLoaderMacOS into DynamicLoaderMacOSXDYLD so that there's one initializer for the DynamicLoaderMacOSXDYLD plugin.
2020-02-12[lldb/Plugins] Move SymbolFileDWARFDebugMap into SymbolFileDWARF (NFCI)Jonas Devlieghere1-3/+0
Move the logic for initialization and termination for SymbolFileDWARFDebugMap into SymbolFileDWARF so that there's one initializer for the SymbolFileDWARF plugin.
2020-02-12[LLDB] Fix GCC warnings about extra semicolons. NFC.Martin Storsjö1-78/+78
2020-02-11[lldb/Plugins] Move PlatformRemoteiOS into PlatformMacOSX (NFCI)Jonas Devlieghere1-3/+0
Move the logic for initialization and termination for PlatformRemoteiOS into PlatformMacOSX, like we did for the other Darwin platforms in a731c6ba94d0464c6a122de1af70ab88ffb5c1a6.
2020-02-07[lldb/Plugin] Use LLDB_PLUGIN_DECLARE to forward declare plugin initializersJonas Devlieghere1-0/+86
Apparently Linux and Windows have the exact opposite behavior when it comes to inline declarations of external functions. On Linux they're considered to be part of the lldb_private namespace, while on Windows they're considered to be part of the top level namespace. Somehow on macOS, it doesn't really matter and both are fine... At this point I don't know what to do, so I'm just adding the LLDB_PLUGIN_DECLARE macros again as originally proposed in D74245.
2020-02-07[lldb/Plugins] Use external functions to (de)initialize pluginsJonas Devlieghere1-250/+163
This is a step towards making the initialize and terminate calls be generated by CMake, which in turn is towards making it possible to disable plugins at configuration time. Differential revision: https://reviews.llvm.org/D74245
2020-02-07[lldb] Group ABI pluginsPavel Labath1-15/+15
Summary: There's a fair amount of code duplication between the different ABI plugins for the same architecture (e.g. ABIMacOSX_arm & ABISysV_arm). Deduplicating this code is not very easy at the moment because there is no good place where to put the common code. Instead of creating more plugins, this patch reduces their number by grouping similar plugins into a single folder/plugin. This makes it easy to extract common code to a (e.g.) base class, which can then live in the same folder. The grouping is done based on the underlying llvm target for that architecture, because the plugins already require this for their operation. Reviewers: JDevlieghere, jasonmolenda, jfb Subscribers: sdardis, nemanjai, mgorny, kristof.beyls, fedor.sergeev, kbarton, jrtc27, atanasyan, jsji, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D74138
2020-02-05Revert "[LLDB] Add DynamicLoaderWasmDYLD plugin for WebAssembly debugging"Pavel Labath1-3/+0
This patch has a couple of outstanding issues. The test is not python3 compatible, and it also seems to fail with python2 (at least under some circumstances) due to an overambitious assertion. This reverts the patch as well as subsequent fixup attempts: 014ea9337624fe20aca8892e73b6b3f741d8da9e, f5f70d1c8fbf12249b4b9598f10a10f12d4db029. 4697e701b8cb40429818609814c7422e49b2ee07. 5c15e8e682e365b3a7fcf35200df79f3fb93b924. 3ec28da6d6430a00b46780555a87acd43fcab790.
2020-02-05Add missing directory from 3ec28da6Derek Schuff1-0/+3
Also revert 4697e701b8, restoring the original patch from https://reviews.llvm.org/D72751
2020-02-05Partially revert "[LLDB] Add DynamicLoaderWasmDYLD plugin for WebAssembly ↵Jonas Devlieghere1-3/+0
debugging" This temporarily and partially reverts 3ec28da6d643 because it's missing a directory.
2020-02-05[LLDB] Add DynamicLoaderWasmDYLD plugin for WebAssembly debuggingPaolo Severini1-0/+3
Add a dynamic loader plug-in class for WebAssembly modules. Differential Revision: https://reviews.llvm.org/D72751
2020-01-31[lldb] Move clang-based files out of SymbolAlex Langford1-1/+1
Summary: This change represents the move of ClangASTImporter, ClangASTMetadata, ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h This explicitly removes knowledge of clang internals from lldbSymbol, moving towards a more generic core implementation of lldb. Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73661
2020-01-23[lldb][NFC] Rename ClangASTContext to TypeSystemClangRaphael Isemann1-3/+3
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-21[lldb/Initializers] Move all ObjC initializers into AppleObjCRuntimeJonas Devlieghere1-6/+3
AppleObjCRuntime is the main entry point to the plugin with the same name. This is part of a greater refactoring to auto generate the initializers. NFC. Differential revision: https://reviews.llvm.org/D73121
2020-01-21[lldb/Plugin] Move DisassemblerLLVMC for consistency with plugin (NFC)Jonas Devlieghere1-1/+1
Rename the DisassemblerLLVMC directory from llvm to LLVMC to match the plugin name.
2020-01-21[lldb/Plugin] Rename MainThreadCheckerRuntime for consistency with plugin (NFC)Jonas Devlieghere1-3/+4
Renames MainThreadCheckerRuntime to InstrumentationRuntimeMainThreadChecker to be consistent with the directory structure and plugin name.
2020-01-21[lldb/Plugin] Rename UBSanRuntime for consistency with plugin (NFC)Jonas Devlieghere1-3/+3
Renames UBSanRuntime to InstrumentationRuntimeUBSan to be consistent with the directory structure and plugin name.
2020-01-21[lldb/Plugin] Rename TSanRuntime for consistency with plugin (NFC)Jonas Devlieghere1-3/+3
Renames TSanRuntime to InstrumentationRuntimeTSan to be consistent with the directory structure and plugin name.
2020-01-21[lldb/Plugin] Rename AddressSanitizerRuntime for consistency with plugin (NFC)Jonas Devlieghere1-3/+3
Renames AddressSanitizerRuntime to InstrumentationRuntimeASan to be consistent with the directory structure and plugin name.
2020-01-21[lldb/tools] Update lldb-test's system initializerJonas Devlieghere1-27/+0
After a731c6ba94d0 the initializer only has to call the PlatformMacOSX to initialize all the macOS platforms.
2020-01-17[lldb][NFC] Resynchronize Init/Terminate calls in ↵Raphael Isemann1-7/+37
SystemInitializerFull/Test.cpp files. These files should do the more or less the same initialize/terminate calls in the same order. This just reverts all the differences that have piled up over time in the SystemInitializerTest that people keep forgetting about.
2020-01-16[LLDB] Add SymbolVendorWasm plugin for WebAssembly debuggingPaolo Severini1-0/+3
Add plugin class SymbolVendorWasm, with the logic to manage debug symbols for Wasm modules. Reviewers: clayborg, labath, aprantl, sbc100, teemperor Reviewed By: labath Tags: #lldb Differential Revision: https://reviews.llvm.org/D72650
2020-01-15[LLDB] Add ObjectFileWasm plugin for WebAssembly debuggingPaolo Severini1-0/+3
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
2019-09-26SystemInitializer: Define macros for experimental targets tooPavel Labath1-0/+2
llvm-svn: 372998
2019-09-26SystemInitializer: Use Targets.def to selectively initialize ABI pluginsPavel Labath1-56/+34
This avoids having to define additional macros in the cmake file, and and also makes the logic in the cpp files more compact. It is also easily extendible to other plugin types (instruction emulation?) that should only be initialized if the corresponding llvm target is built. Thanks to Ilya Birukov for pointing me to this file. llvm-svn: 372952
2019-09-25Have ABI plugins vend llvm MCRegisterInfo dataPavel Labath1-14/+46
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-04-10[NFC] Remove ASCII lines from commentsJonas Devlieghere1-2/+0
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
2019-03-27[Platform] Remove Kalimba PlatformJonas Devlieghere1-3/+0
This patch removes the Kalimba platform. For more information please refer to the corresponding thread on the mailing list. http://lists.llvm.org/pipermail/lldb-dev/2019-March/014921.html llvm-svn: 357086
2019-02-21[Reproducers] Initialize reproducers before initializing the debugger.Jonas Devlieghere1-3/+2
As per the discussion on the mailing list: http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html This commit implements option (3): > Go back to initializing the reproducer before the rest of the debugger. > The method wouldn't be instrumented and guarantee no other SB methods are > called or SB objects are constructed. The initialization then becomes part > of the replay. Differential revision: https://reviews.llvm.org/D58410 llvm-svn: 354631
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-11Introduce SymbolFileBreakpad and use it to fill symtabPavel Labath1-0/+3
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
2018-12-10Re-commit "Introduce ObjectFileBreakpad"Pavel Labath1-0/+3
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-07Revert "Introduce ObjectFileBreakpad"Shafik Yaghmour1-3/+0
This reverts commit 5e056e624cc57bb22a4c29a70b522783c6242293. Reverting because this lldb cmake bot: http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/13712/ llvm-svn: 348629
2018-12-07Introduce ObjectFileBreakpadPavel Labath1-0/+3
Summary: 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: 348592
generated by cgit v1.1 at 2025-10-03 20:53:26 +0000