summaryrefslogtreecommitdiff
path: root/lldb/source
Commit message (Collapse)AuthorAgeFilesLines
* [lldb][NFCI] Move ThreadSafeDenseMap to UtilityAlex Langford2023-05-172-2/+2
| | | | This seems better suited for Utility than Core
* [lldb][SymbolFileDWARF] Fix format specifier when logging ↵Michael Buch2023-05-171-2/+2
| | | | | | | | | | | | | | | | | | FindDefinitionTypeForDWARFDeclContext Before: ``` (arm64) /Users/michaelbuch/Git/lldb-build-main-modules/module.cache/295JG6LDUQX5Z/Clang_AST-39AVV87GST1ON.pcm: SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(tag=%s, name='DW_TAG_class_type') ``` After: ``` (arm64) /Users/michaelbuch/Git/lldb-build-main-modules/module.cache/295JG6LDUQX5Z/std-XGBT2D5Y2D6X.pcm: SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(tag=DW_TAG_class_type, name='reverse_iterator<std::__1::__wrap_iter<char *> >') ```
* [lldb][gnustep] Add minimal GNUstepObjCRuntime plugin for LanguageTypeObjC ↵Stefan Gränitz2023-05-177-4/+364
| | | | | | | | | | | | | | on non-Apple platforms This is the next patch after D146058. We can now parse expressions to print instance variables from ObjC classes. Until now the expression parser would bail out with an error like this: ``` error: expression failed to parse: error: Error [IRForTarget]: Couldn't find Objective-C indirect ivar symbol OBJC_IVAR_$_TestObj._int ``` Reviewed By: aprantl Differential Revision: https://reviews.llvm.org/D146154
* lldb PlatformDarwinKernel make local filesystem scan lazyJason Molenda2023-05-162-6/+15
| | | | | | | | | Instead of doing the local filesystem scan for kexts and kernels when the PlatformDarwinKernel is constructed, delay doing it until the scan is needed. Differential Revision: https://reviews.llvm.org/D150621 rdar://109186357
* [lldb][NFCI] Small adjustment to Breakpoint::AddNameAlex Langford2023-05-161-1/+1
| | | | | | m_name_list is a std::unordered_set<std::string>, we can insert the string directly instead of grabbing the c_str and creating yet another one.
* [lldb] Define lldbassert based on NDEBUG instead of LLDB_CONFIGURATION_DEBUGJonas Devlieghere2023-05-161-6/+2
| | | | | | | | | | | Whether assertions are enabled or not is orthogonal to the build type which could lead to surprising behavior for lldbassert. Previously, when doing a debug build with assertions disabled, lldbassert would become a NOOP, rather than printing an error like it does in a release build. By definining lldbassert in terms of NDEBUG, it behaves like a regular assert when assertions are enabled, and like a soft assert. Differential revision: https://reviews.llvm.org/D150639
* [lldb][DWARFASTParserClang] Don't create unnamed bitfields to account for ↵Michael Buch2023-05-162-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vtable pointer **Summary** When filling out the LayoutInfo for a structure with the offsets from DWARF, LLDB fills gaps in the layout by creating unnamed bitfields and adding them to the AST. If we don't do this correctly and our layout has overlapping fields, we will hat an assertion in `clang::CGRecordLowering::lower()`. Specifically, if we have a derived class with a VTable and a bitfield immediately following the vtable pointer, we create a layout with overlapping fields. This is an oversight in some of the previous cleanups done around this area. In `D76808`, we prevented LLDB from creating unnamed bitfields if there was a gap between the last field of a base class and the start of a bitfield in the derived class. In `D112697`, we started accounting for the vtable pointer. The intention there was to make sure the offset bookkeeping accounted for the existence of a vtable pointer (but we didn't actually want to create any AST nodes for it). Now that `last_field_info.bit_size` was being set even for artifical fields, the previous fix `D76808` broke specifically for cases where the bitfield was the first member of a derived class with a vtable (this scenario wasn't tested so we didn't notice it). I.e., we started creating redundant unnamed bitfields for where the vtable pointer usually sits. This confused the lowering logic in clang. This patch adds a condition to `ShouldCreateUnnamedBitfield` which checks whether the first field in the derived class is a vtable ptr. **Testing** * Added API test case Differential Revision: https://reviews.llvm.org/D150591
* [lldb][DWARFASTParserClang][NFC] Extract condition for unnamed bitfield ↵Michael Buch2023-05-162-12/+44
| | | | | | | | | | | | | | | | | | creation into helper function This patch adds a new private helper `DWARFASTParserClang::ShouldCreateUnnamedBitfield` which `ParseSingleMember` whether we should fill the current gap in a structure layout with unnamed bitfields. Extracting this logic will allow us to add additional conditions in upcoming patches without jeoperdizing readability of `ParseSingleMember`. We also store some of the boolean conditions in local variables to make the intent more obvious. Differential Revision: https://reviews.llvm.org/D150590
* [lldb][DWARFASTParserClang][NFC] Simplify unnamed bitfield conditionMichael Buch2023-05-161-7/+4
| | | | | | | | | | Minor cleanup of redundant variable initialization and if-condition. These are leftovers/oversights from previous cleanup in this area: * https://reviews.llvm.org/D72953 * https://reviews.llvm.org/D76808 Differential Revision: https://reviews.llvm.org/D150589
* [lldb] Fix lua build after 27b6a4e63afeAlex Langford2023-05-152-10/+17
| | | | | | | This applies the same trick for Lua that I did for python in 27b6a4e63afe. Differential Revision: https://reviews.llvm.org/D150624
* [lldb] Refine call to decl printing helper (NFC)Dave Lee2023-05-151-1/+6
| | | | | | | | | | | | | | | | | | When `ValueObjectPrinter` calls its `m_decl_printing_helper`, not all state is passed to the helper. In particular, the helper doesn't have access to `m_curr_depth`, and thus can't act on the logic within `ShouldShowName`. To address this, this change passes in a modified copy of `m_options`. The modified copy has has `m_hide_name` set according to the results of `ShouldShowName`. This allows helper functions to know whether the name should be shown or hidden, without having access to `ValueObjectPrinter`'s full state. This is NFC in mainline lldb, as the only decl printing helper doesn't make use of this. However in swift-lldb at least, there are decl printing helpers that do need this information passed to them. See https://github.com/apple/llvm-project/pull/6795 where a test is also included. Differential Revision: https://reviews.llvm.org/D150129
* [lldb] Change definition of DisassemblerCreateInstanceAlex Langford2023-05-153-18/+12
| | | | | | | | | DissassemblerCreateInstance is a function pointer whos return type is `Disassembler *`. But Disassembler::FindPlugin always returns a DisassemblerSP, so there's no reason why we can't just create a DisassemblerSP in the first place. Differential Revision: https://reviews.llvm.org/D150235
* Revert "[lldb] Refactor SBFileSpec::GetDirectory"Muhammad Omair Javaid2023-05-151-1/+3
| | | | | | | | | | | This reverts commit 2bea2d7b070dc5df723ce2b92dbc654b8bb1847e. It introduced following failures on buildbot lldb-aarch64-windows: lldb-api :: functionalities/process_save_core/TestProcessSaveCore.py lldb-api :: python_api/symbol-context/TestSymbolContext.py Differential Revision: https://reviews.llvm.org/D149625
* [lldb] Cleanup OptionValue header and implenentation (NFC)Jonas Devlieghere2023-05-141-26/+13
| | | | | Group related functions together and remove inconsistencies between them in the implementation.
* [lldb] Complete OptionValue cleanup (NFC)Jonas Devlieghere2023-05-1413-30/+35
| | | | | Make the `Get.*Value` and `Set.*Value` function private and migrate the last remaining call sites to the new overloaded/templated functions.
* [lldb][NFCI] Replace use of DWARFAttribute in DWARFAbbreviationDeclAlex Langford2023-05-123-17/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DWARFAttribute is used in 2 classes: DWARFAbbreviationDecl and DWARFAttributes. The former stores a std::vector of them and the latter has a small structure called AttributeValue that contains a DWARFAttribute. DWARFAttributes maintains a llvm::SmallVector of AttributeValues. My end goal is to have `DWARFAttributes` have a llvm::SmallVector specialized on DWARFAttribute. In order to do that, we'll have to move the other elements of AttributeValue into DWARFAttribute itself. But we don't want to do this while DWARFAbbreviationDecl is using DWARFAttribute because it will needlessly increase the size of DWARFAbbreviationDecl. So instead I will create a small type containing only what DWARFAbbreviationDecl needs and call it `AttributeSpec`. This is the exact same thing that LLVM does today. I've elected to swap std::vector for llvm::SmallVector here with a pre-allocated size of 8. I've collected time and memory measurements before this change and after it as well. Using a c++ project with 10,000 object files and no dSYM, I place a breakpoint by file + lineno and see how long it takes to resolve. Before this patch: Time (mean ± σ): 13.577 s ± 0.024 s [User: 12.418 s, System: 1.247 s] Total number of bytes allocated: 1.38 GiB Total number of allocations: 6.47 million allocations After this patch: Time (mean ± σ): 13.287 s ± 0.020 s [User: 12.128 s, System: 1.250 s] Total number of bytes allocated: 1.59 GiB Total number of allocations: 4.61 million allocations So we consume more memory than before, but we actually make less allocations on average. I also measured with an llvm::SmallVector with a pre-allocated size of 4 instead of 8 to measure how well it performs: Time (mean ± σ): 13.246 s ± 0.048 s [User: 12.074 s, System: 1.268 s] Total memory consumption: 1.50 GiB Total number of allocations: 5.74 million Of course this data may look very different depending on the actual program being debugged, but each of the object files had 100+ AbbreviationDeclarations each with between 0 and 10 Attributes, so I feel this was a fair example to consider. Differential Revision: https://reviews.llvm.org/D150418
* [lldb][NFCI] Delete commented out method OptionValueProperties::GetQualifiedNameAlex Langford2023-05-121-19/+0
|
* [lldb][NFCI] Change return type of DWARFDebugInfoEntry::GetAttributesAlex Langford2023-05-129-355/+342
| | | | | | | | | | | | The purpose of this method is to get the list of attributes of a DebugInfoEntry. Prior to this change we were passing in a mutable reference to a DWARFAttributes object and having the method fill it in for us while returning the size of the filled out list. But instead of doing that, we can just return a `DWARFAttributes` object ourselves since every caller creates a new list before calling GetAttributes. Differential Revision: https://reviews.llvm.org/D150402
* [lldb][NFCI] Redefine dw_attr_t typedef with llvm::dwarf::AttributeAlex Langford2023-05-124-1/+7
| | | | | | | | | Similar to dw_form_t, dw_attr_t is typedef'd to be a uint16_t. LLVM defines their type `llvm::dwarf::Attribute` as an enum backed by a uint16_t. Switching to the LLVM type buys us type checking and the requirement of explicit casts. Differential Revision: https://reviews.llvm.org/D150299
* Fix libstdc++ data formatter for reference/pointer to std::stringJeffrey Tan2023-05-121-2/+9
| | | | | | | This patch fixes libstdc++ data formatter for reference/pointer to std::string. The failure testcases are added which succeed with the patch. Differential Revision: https://reviews.llvm.org/D150313
* [lldb][nfc] Simplify DebugRanges classFelipe de Azevedo Piovezan2023-05-123-64/+16
| | | | | | | | | | | | | | | | Most of the code changed here dates back to 2010, when LLDB was first introduced upstream, as such it benefits from a slight cleanup. The method "dump" is not used anywhere nor is it tested, so this commit removes it. The "findRanges" method returns a boolean which is never checked and indicates whether the method found anything/assigned a range map to the out parameter. This commit folds the out parameter into the return type of the method. A handful of typedefs were also never used and therefore removed. Differential Revision: https://reviews.llvm.org/D150363
* We can't let GetStackFrameCount get interrupted or it will give theJim Ingham2023-05-113-19/+45
| | | | | | | | | | | | | | | | | | | | | | | | wrong answer. Plus, it's useful in some places to have a way to force the full stack to be created even in the face of interruption. Moreover, most of the time when you're just getting frames, you don't need to know the number of frames in the stack to start with. You just keep calling Thread::GetStackFrameAtIndex(index++) and when you get a null StackFrameSP back, you're done. That's also more amenable to interruption if you are doing some work frame by frame. So this patch makes GetStackFrameCount always return the full count, suspending interruption. I also went through all the places that use GetStackFrameCount to make sure that they really needed the full stack walk. In many cases, they did not. For instance frame select -r 10 was getting the number of frames just to check whether cur_frame_idx + 10 was within the stack. It's better in that case to see if that frame exists first, since that doesn't force a full stack walk, and only deal with walking off the end of the stack if it doesn't... I also added a test for some of these behaviors. Differential Revision: https://reviews.llvm.org/D150236
* [lldb] Correct elision of line zero in mixed disassemblyDave Lee2023-05-111-1/+1
| | | | | | When `disassemble --mixed` is run, do not show source for line zero, as intended. Differential Revision: https://reviews.llvm.org/D150383
* Prioritize using a segment with the name TEXT instead off fileoff 0Jason Molenda2023-05-101-8/+10
| | | | | | | | | | | | | | | | | lldb needs to find the virtual address of the mach header of a binary. It first scans for a segment which starts at file offset 0, and uses the vmaddr of that segment. If no segment starts at fileoff 0, it looks for a segment named __TEXT. This patch changes the order of those, to first search for the TEXT segment. We have a situation where binaries exist that have the DATA segment first, which does not have the vmaddr of the mach header, it merely happens to come first in the binary file. It's an unusual arrangement, but not breaking any rules of Mach-O. So lldb needs to handle this. Differential Revision: https://reviews.llvm.org/D150239 rdar://109128418
* When the Debugger runs HandleProcessEvent it should allowJim Ingham2023-05-101-2/+4
| | | | | | | | | | | | | | | | selecting the "Most relevant" frame. If you don't do that, then the correct frame gets selected, but it happens AFTER the frame info gets printed in the stop message, so you don't see the selected frame. The test for this hid the issue because it ran `frame info` and checked the result of that. That happens after the recognizer selects the frame, and so it was right. But if the recognizer is working correctly it will have already done the same printing in the stop message, and this way we also verify that the stop message was right. Differential Revision: https://reviews.llvm.org/D150315
* [lldb] Mark most SBAPI methods involving private types as protected or privateAlex Langford2023-05-109-255/+288
| | | | | | | | | | | | | | | | | | | | | Many SB classes have public constructors or methods involving types that are private. Some are more obvious (e.g. containing lldb_private in the name) than others (lldb::FooSP is usually std::shared_pointer<lldb_private::Foo>). This commit explicitly does not address FileSP, so I'm leaving that one alone for now. Some of these were for other SB classes to use and should have been made protected/private with a friend class entry added. Some of these were public for some of the swig python helpers to use. I put all of those functions into a class and made them static methods. The relevant SB classes mark that class as a friend so they can access those private/protected members. I've also removed an outdated SBStructuredData test (can you guess which constructor it was using?) and updated the other relevant tests. Differential Revision: https://reviews.llvm.org/D150157
* [lldb][NFCI] Replace dw_form_t with llvm::dwarf::FormAlex Langford2023-05-107-14/+21
| | | | | | | | | | | | | | | | LLDB currently defines `dw_form_t` as a `uint16_t` which makes sense. However, LLVM also defines a similar type `llvm::dwarf::Form` which is an enum backed by a `uint16_t`. Switching to the llvm implementation means that we can more easily interoperate with the LLVM DWARF code. Additionally, we get some type checking out of this: I found that DWARFAttribute had a method called `FormAtIndex` that returned a `dw_attr_t`. Although `dw_attr_t` is also a `uint16_t` under the hood, the type checking benefits here are undeniable: If this had returned a something of different signedness/width, we could have had some bad bugs. Differential Revision: https://reviews.llvm.org/D150228
* [lldb][NFCI] Remove n^2 loops and simplify iterator usageFelipe de Azevedo Piovezan2023-05-101-34/+25
| | | | | | | | | | | | | | | | | | The code inside Broadcaster makes usage of iterators using olden C++ coding style. Hidden in this old style is a couple of N^2 loops: we iterate over a map (sequentially), removing the first element that matches some predicate. The search is _always_ done from the start of the map, which implies that, if the map has N elements and if all matches happen on the second half of the map, then we visit the first N/2 elements exactly N/2 * N/2 times. Ideally some of the code here would benefit from `std::map`s own "erase_if", but this is only available with C++20: https://en.cppreference.com/w/cpp/container/map/erase_if We spent quite some time trying to make these loops more elegant, but it is surprisingly tricky to do so. Differential Revision: https://reviews.llvm.org/D150219
* [nfc] Remove dead code from ObjectFileMachOJason Molenda2023-05-091-49/+0
| | | | | | The old way of lldb reading the on-disk shared cache is still in the sources, but we use dyld SPI to inspect this binary now. This code is no longer called.
* [lldb][NFCI] Remove custom dwarf LEB128 typesAlex Langford2023-05-094-11/+10
| | | | | | | | | | The LEB128 type defined by the DWARF standard is explicitly a variable-length encoding of an integer. LLDB had defined `uleb128` and `sleb128` types to be 32-bit but in many places in both LLVM and LLDB we treat the maximum width of LEB128 types to be 64, so let's remove these types and be consistent. Differential Revision: https://reviews.llvm.org/D150222
* [lldb] Simplify Log::PutString (NFC)Dave Lee2023-05-091-13/+12
| | | | | | | * As no format string is involved, avoid unecessary call into `Printf` * Eliminate creation of a `std::string` to print a `StringRef` Differential Revision: https://reviews.llvm.org/D150160
* [lldb] Simplify predicates of find_if in BroadcastManagerAlex Langford2023-05-091-15/+44
| | | | | | | We had some custom classes that were used as the predicate for `std::find_if`. It would be a lot simpler if we used lambdas instead. Differential Revision: https://reviews.llvm.org/D150168
* Add a new report_load_commands option to jGetLoadedDynamicLibrariesInfosJason Molenda2023-05-083-13/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | jGetLoadedDynamicLibrariesInfos has a mode where it will list every binary in the process - the load address and filepath from dyld SPI, and the mach-o header and load commands from a scan by debugserver for perf reasons. With a large enough number of libraries, creating that StructuredData representation of all of this, and formatting it into an ascii string to send up to lldb, can grow debugserver's heap size too large for some environments. This patch adds a new report_load_commands:false boolean to the jGetLoadedDynamicLibrariesInfos packet, where debugserver will now only report the dyld SPI load address and filepath for all of the binaries. lldb can then ask for the detailed information on the process binaries in smaller chunks, and avoid debugserver having ever growing heap use as the number of binaries inevitably increases. This patch also removes a version of jGetLoadedDynamicLibrariesInfos for pre-iOS 10 and pre-macOS 10.12 systems where we did not use dyld SPI. We can't back compile to those OS builds any longer with modern Xcode. Finally, it removes a requirement in DynamicLoaderMacOS that the JSON reply from jGetLoadedDynamicLibrariesInfos include the mod_date field for each binary. This has always been reported as 0 in modern dyld, and is another reason for packet growth in the reply. debugserver still puts the mod_date field in its replies for interop with existing lldb's, but we will be able to remove it the field from debugserver's output after the next release cycle when this patch has had time to circulate. I'll add lldb support for requesting the load addresses only and splitting the request up into chunks in a separate patch. Differential Revision: https://reviews.llvm.org/D150158 rdar://107848326
* [lldb] Prevent mutation of CommandAlias::GetOptionArgumentsDave Lee2023-05-081-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Fix a mutation of `CommandAlias::m_option_args_sp`, which resulted in cases where aliases would fail to run on second, and subsequent times. For example, an alias such as: ``` command alias p1 p 1 ``` When run the second time, the following error would be reported to the user: ``` error: expression failed to parse: error: <user expression 1>:1:1: expression is not assignable -- 1 ^ ~ ``` To fix this, `CommandAlias::Desugar` now constructs options to a freshly constructed vector, rather than by appending to the results of `GetOptionArguments`. rdar://107770836 Differential Revision: https://reviews.llvm.org/D150078
* ObjectFile: introduce a COFF object file pluginSaleem Abdulrasool2023-05-074-0/+441
| | | | | | | | | | | | | Windows uses COFF as an object file format and PE/COFF as an executable file format. They are subtly different and certain elements of a COFF file may not be present in an executable. Introduce a new plugin to add support for the COFF object file format which is required to support loading of modules built with -gmodules. This is motivated by Swift which serialises debugging information into a PCM which is a COFF object file. Differential Revision: https://reviews.llvm.org/D149987 Reviewed By: bulbazord
* [lldb] [NetBSD] getValue => operator* for Optional migrationNikita Ronja Gillmann2023-05-071-2/+2
| | | | Differential Revision: https://reviews.llvm.org/D150032
* [lldb] Replace None with std::nullopt in comments (NFC)Kazu Hirata2023-05-063-4/+4
| | | | | | | This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
* [LLDB] Add minimal support for the new Mojo languagewalter erquinigo2023-05-051-0/+1
| | | | Modular just announced a new language called Mojo. This patch adds an entry in the language list in LLDB for minimal support (e.g. being able to create a TypeSystem for this language). We will later add debug info entries when the language matures.
* [lldb] Fix fallout from e9eaf7b430eeAlex Langford2023-05-051-1/+1
| | | | Minor logic mistake. This caused TestObjCClassMethod to fail.
* [lldb] Migrate to GetPropertyAtIndexAs for ArchSpec (NFC)Jonas Devlieghere2023-05-053-17/+18
| | | | Use the templated GetPropertyAtIndexAs helper for ArchSpec.
* [lldb] Migrate to GetPropertyAtIndexAs for LanguageType (NFC)Jonas Devlieghere2023-05-053-20/+3
| | | | Use the templated GetPropertyAtIndexAs helper for LanguageType.
* Re-land "[lldb] Expose a const iterator for SymbolContextList"Alex Langford2023-05-0517-359/+213
| | | | | | | Re-lands 04aa943be8ed5c03092e2a90112ac638360ec253 with modifications to fix tests. I originally reverted this because it caused a test to fail on Linux. The problem was that I inverted a condition on accident.
* ObjectFile: remove extraneous shadowed variable (NFCI)Saleem Abdulrasool2023-05-051-1/+0
| | | | | We already construct the shared pointer for the module. Avoid creating a shadow copy and use the original definition.
* [lldb][TypeSystem] ForEach: Don't hold the TypeSystemMap lock across callbackMichael Buch2023-05-051-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `TypeSystemMap::m_mutex` guards against concurrent modifications of members of `TypeSystemMap`. In particular, `m_map`. `TypeSystemMap::ForEach` iterates through the entire `m_map` calling a user-specified callback for each entry. This is all done while `m_mutex` is locked. However, there's nothing that guarantees that the callback itself won't call back into `TypeSystemMap` APIs on the same thread. This lead to double-locking `m_mutex`, which is undefined behaviour. We've seen this cause a deadlock in the swift plugin with following backtrace: ``` int main() { std::unique_ptr<int> up = std::make_unique<int>(5); volatile int val = *up; return val; } clang++ -std=c++2a -g -O1 main.cpp ./bin/lldb -o “br se -p return” -o run -o “v *up” -o “expr *up” -b ``` ``` frame #4: std::lock_guard<std::mutex>::lock_guard frame #5: lldb_private::TypeSystemMap::GetTypeSystemForLanguage <<<< Lock #2 frame #6: lldb_private::TypeSystemMap::GetTypeSystemForLanguage frame #7: lldb_private::Target::GetScratchTypeSystemForLanguage ... frame #26: lldb_private::SwiftASTContext::LoadLibraryUsingPaths frame #27: lldb_private::SwiftASTContext::LoadModule frame #30: swift::ModuleDecl::collectLinkLibraries frame #31: lldb_private::SwiftASTContext::LoadModule frame #34: lldb_private::SwiftASTContext::GetCompileUnitImportsImpl frame #35: lldb_private::SwiftASTContext::PerformCompileUnitImports frame #36: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetSwiftASTContext frame #37: lldb_private::TypeSystemSwiftTypeRefForExpressions::GetPersistentExpressionState frame #38: lldb_private::Target::GetPersistentSymbol frame #41: lldb_private::TypeSystemMap::ForEach <<<< Lock #1 frame #42: lldb_private::Target::GetPersistentSymbol frame #43: lldb_private::IRExecutionUnit::FindInUserDefinedSymbols frame #44: lldb_private::IRExecutionUnit::FindSymbol frame #45: lldb_private::IRExecutionUnit::MemoryManager::GetSymbolAddressAndPresence frame #46: lldb_private::IRExecutionUnit::MemoryManager::findSymbol frame #47: non-virtual thunk to lldb_private::IRExecutionUnit::MemoryManager::findSymbol frame #48: llvm::LinkingSymbolResolver::findSymbol frame #49: llvm::LegacyJITSymbolResolver::lookup frame #50: llvm::RuntimeDyldImpl::resolveExternalSymbols frame #51: llvm::RuntimeDyldImpl::resolveRelocations frame #52: llvm::MCJIT::finalizeLoadedModules frame #53: llvm::MCJIT::finalizeObject frame #54: lldb_private::IRExecutionUnit::ReportAllocations frame #55: lldb_private::IRExecutionUnit::GetRunnableInfo frame #56: lldb_private::ClangExpressionParser::PrepareForExecution frame #57: lldb_private::ClangUserExpression::TryParse frame #58: lldb_private::ClangUserExpression::Parse ``` Our solution is to simply iterate over a local copy of `m_map`. **Testing** * Confirmed on manual reproducer (would reproduce 100% of the time before the patch) Differential Revision: https://reviews.llvm.org/D149949
* SymbolFile: invert condition, remove unnecessary `else` (NFC)Saleem Abdulrasool2023-05-051-3/+2
| | | | | Remove an unnecessary `else` condition and swap the condition to be positive rather than negative to make simpler to follow. NFC
* Reland "[lldb][DWARFExpression] Fix DW_OP_div to use signed division"LU Hongyi2023-05-051-2/+6
| | | | | | | | | | | | | | | | | | | This patch resolves an issue where a value is incorrectly displayed if it is represented by DW_OP_div. This issue is caused by lldb evaluating operands of DW_OP_div as unsigned and performed unintended unsigned division. This issue is resolved by creating two temporary signed scalar and performing signed division. (Addresses GH#61727) Differential Revision: https://reviews.llvm.org/D147370
* [lldb] Migrate to GetPropertyAtIndexAs for FileSpecList (NFC)Jonas Devlieghere2023-05-045-27/+17
| | | | Use the templated GetPropertyAtIndexAs helper for FileSpecList.
* [lldb] Eliminate {Get,Set}PropertyAtIndexAsFileSpec (NFC)Jonas Devlieghere2023-05-049-49/+23
| | | | | This patch is a continuation of 6f8b33f6dfd0 and eliminates the {Get,Set}PropertyAtIndexAsFileSpec functions.
* [lldb] Move Core/FileSpecList -> Utility/FileSpecList (NFC)Jonas Devlieghere2023-05-0417-21/+19
| | | | | There's no reason for FileSpecList to live in lldb/Core while FileSpec lives in lldb/Utility. Move FileSpecList next to FileSpec.
* [lldb] Remove SetPropertyAtIndexAsLanguage (NFC)Jonas Devlieghere2023-05-041-11/+0
| | | | After 6f8b33f6dfd0 this function has no callers anymore.
View Lorry Controller Status