| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[lldb] Use UnwindPlan::Row as values (#131150) In most places, the rows are copied anyway (because they are generated by cumulating modifications) immediately after adding them to the unwind plans. In others, they can be moved into the unwind plan. This lets us remove some backflip copies and make const UnwindPlan actually mean something. I've split this patch into two (and temporarily left both APIs) as this patch was getting a bit big. This patch covers all the interesting cases. Part two all about converting "architecture default" unwind plans from ABI and InstructionEmulation plugins. | 1 年前 | |
[lldb] Fix block address resolution for functions in multiple sections (#137955) Continuing the theme from #116777 and #124931, this patch ensures we compute the correct address when a functions is spread across multiple sections. Due to this, it's not sufficient to adjust the offset in the section+offset pair (Address::Slide). We must actually slide the file offset and then recompute the section using the result. I found this out due to a failure to disassemble some parts of the function, so I'm testing with that, although it's likely there are other things that were broken due to this. | 1 年前 | |
[lldb/cmake] Use ADDITIONAL_HEADER(_DIR)?S (#142587) Replace (questionable) header globs with an explicit argument supported by llvm_add_library. | 1 年前 | |
[lldb] Remove unused UnwindPlan functions (#134630) GetLSDAAddress and GetPersonalityRoutinePtrAddress are unused and they create a bit of a problem for discontinuous functions, because the unwind plan for these consists of multiple eh_frame descriptors and (at least in theory) each of them could have a different value for these entities. We could say we only support functions for which these are always the same, or create some sort of a Address2LSDA lookup map, but I think it's better to leave this question to someone who actually needs this. | 1 年前 | |
[lldb] Eliminate SupportFileSP nullptr derefs (#168624) This patch fixes and eliminates the possibility of SupportFileSP ever being nullptr. The support file was originally treated like a value type, but became a polymorphic type and therefore has to be stored and passed around as a pointer. To avoid having all the callers check the validity of the pointer, I introduced the invariant that SupportFileSP is never null and always default constructed. However, without enforcement at the type level, that's fragile and indeed, we already identified two crashes where someone accidentally broke that invariant. This PR introduces a NonNullSharedPtr to prevent that. NonNullSharedPtr is a smart pointer wrapper around std::shared_ptr that guarantees the pointer is never null. If default-constructed, it creates a default-constructed instance of the contained type. Note that I'm using private inheritance because you shouldn't inherit from standard library classes due to the lack of virtual destructor. So while the new abstraction looks like a std::shared_ptr, it is in fact **not** a shared pointer. Given that our destructor is trivial, we could use public inheritance, but currently there's no need for it. rdar://164989579 | 8 个月前 | |
[lldb] Add SB API to access static constexpr member values (#89730) The main change is the addition of a new SBTypeStaticField class, representing a static member of a class. It can be retrieved created through SBType::GetStaticFieldWithName. It contains several methods (GetName, GetMangledName, etc.) whose meaning is hopefully obvious. The most interesting method is lldb::SBValue GetConstantValue(lldb::SBTarget) which returns a the value of the field -- if it is a compile time constant. The reason for that is that only constants have their values represented in the clang AST. For non-constants, we need to go back to the module containing that constant, and ask retrieve the associated ValueObjectVariable. That's easy enough if the we are still in the type system of the module (because then the type system will contain the pointer to the module symbol file), but it's hard when the type has been copied into another AST (e.g. during expression evaluation). To do that we would need to walk the ast import chain backwards to find the source TypeSystem, and I haven't found a nice way to do that. Another possibility would be to use the mangled name of the variable to perform a lookup (in all modules). That is sort of what happens when evaluating the variable in an expression (which does work), but I did not want to commit to that implementation as it's not necessary for my use case (and if anyone wants to, he can use the GetMangledName function and perform the lookup manually). The patch adds a couple of new TypeSystem functions to surface the information needed to implement this functionality. | 2 年前 | |
[lldb] Make only one function that needs to be implemented when searching for types (#74786) This patch revives the effort to get this Phabricator patch into upstream: https://reviews.llvm.org/D137900 This patch was accepted before in Phabricator but I found some -gsimple-template-names issues that are fixed in this patch. A fixed up version of the description from the original patch starts now. This patch started off trying to fix Module::FindFirstType() as it sometimes didn't work. The issue was the SymbolFile plug-ins didn't do any filtering of the matching types they produced, and they only looked up types using the type basename. This means if you have two types with the same basename, your type lookup can fail when only looking up a single type. We would ask the Module::FindFirstType to lookup "Foo::Bar" and it would ask the symbol file to find only 1 type matching the basename "Bar", and then we would filter out any matches that didn't match "Foo::Bar". So if the SymbolFile found "Foo::Bar" first, then it would work, but if it found "Baz::Bar" first, it would return only that type and it would be filtered out. Discovering this issue lead me to think of the patch Alex Langford did a few months ago that was done for finding functions, where he allowed SymbolFile objects to make sure something fully matched before parsing the debug information into an AST type and other LLDB types. So this patch aimed to allow type lookups to also be much more efficient. As LLDB has been developed over the years, we added more ways to to type lookups. These functions have lots of arguments. This patch aims to make one API that needs to be implemented that serves all previous lookups: - Find a single type - Find all types - Find types in a namespace This patch introduces a TypeQuery class that contains all of the state needed to perform the lookup which is powerful enough to perform all of the type searches that used to be in our API. It contain a vector of CompilerContext objects that can fully or partially specify the lookup that needs to take place. If you just want to lookup all types with a matching basename, regardless of the containing context, you can specify just a single CompilerContext entry that has a name and a CompilerContextKind mask of CompilerContextKind::AnyType. Or you can fully specify the exact context to use when doing lookups like: CompilerContextKind::Namespace "std" CompilerContextKind::Class "foo" CompilerContextKind::Typedef "size_type" This change expands on the clang modules code that already used a vector<CompilerContext> items, but it modifies it to work with expression type lookups which have contexts, or user lookups where users query for types. The clang modules type lookup is still an option that can be enabled on the TypeQuery objects. This mirrors the most recent addition of type lookups that took a vector<CompilerContext> that allowed lookups to happen for the expression parser in certain places. Prior to this we had the following APIs in Module: void Module::FindTypes(ConstString type_name, bool exact_match, size_t max_matches, llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files, TypeList &types); void Module::FindTypes(llvm::ArrayRef<CompilerContext> pattern, LanguageSet languages, llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files, TypeMap &types); void Module::FindTypesInNamespace(ConstString type_name, const CompilerDeclContext &parent_decl_ctx, size_t max_matches, TypeList &type_list); The new Module API is much simpler. It gets rid of all three above functions and replaces them with: void FindTypes(const TypeQuery &query, TypeResults &results); The TypeQuery class contains all of the needed settings: - The vector<CompilerContext> that allow efficient lookups in the symbol file classes since they can look at basename matches only realize fully matching types. Before this any basename that matched was fully realized only to be removed later by code outside of the SymbolFile layer which could cause many types to be realized when they didn't need to. - If the lookup is exact or not. If not exact, then the compiler context must match the bottom most items that match the compiler context, otherwise it must match exactly - If the compiler context match is for clang modules or not. Clang modules matches include a Module compiler context kind that allows types to be matched only from certain modules and these matches are not needed when d oing user type lookups. - An optional list of languages to use to limit the search to only certain languages The TypeResults object contains all state required to do the lookup and store the results: - The max number of matches - The set of SymbolFile objects that have already been searched - The matching type list for any matches that are found The benefits of this approach are: - Simpler API, and only one API to implement in SymbolFile classes - Replaces the FindTypesInNamespace that used a CompilerDeclContext as a way to limit the search, but this only worked if the TypeSystem matched the current symbol file's type system, so you couldn't use it to lookup a type in another module - Fixes a serious bug in our FindFirstType functions where if we were searching for "foo::bar", and we found a "baz::bar" first, the basename would match and we would only fetch 1 type using the basename, only to drop it from the matching list and returning no results | 2 年前 | |
[LLDB] Add unary plus and minus to DIL (#155617) This patch adds unary nodes plus and minus, introduces unary type conversions, and adds integral promotion to the type system. | 8 个月前 | |
[LLDB] Fix 64 bit support for CIE and FDE handling in DWARFCallFrameInfo (#158350) - Introduced a new helper function IsCIEMarker to determine if a given cie_id indicates a CIE (Common Information Entry) or FDE (Frame Description Entry). - New helper function can now correctly identify both 32-bit and 64-bit CIE based on the DWARF specifications. - Updated the ParseCIE and GetFDEIndex methods to utilize the new helper function for improved clarity and correctness in identifying CIE and FDE entries. - Replaced direct comparisons with UINT32_MAX and UINT64_MAX with std::numeric_limits for better readability. | 10 个月前 | |
[lldb][NFC] Fix all formatting errors in .cpp file headers Summary: A *.cpp file header in LLDB (and in LLDB) should like this: //===-- TestUtilities.cpp -------------------------------------------------===// However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator -*- C++ -*- is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing ===// (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258 | 6 年前 | |
[lldb][NFC] Remove outdated FIXME | 4 年前 | |
[lldb] Disable some unwind plans for discontinuous functions (#140927) Basically, disable everything except the eh_frame unwind plan, as that's the only one which supports this right now. The other plans are working with now trying the interpret everything in between the function parts as a part of the function, which is more likely to produce wrong results than correct ones. I changed the interface for object file plans, to give the implementations a chance to implement this correctly, but I haven't actually converted PECallFrameInfo (its only implementation) to handle that. (from the looks of things, it should be relatively easy to do, if it becomes necessary) I'm also deleting UnwindPlan::GetFirstNonPrologueInsn, as it's not used, and it doesn't work for discontinuous functions. | 1 年前 | |
[lldb] Eliminate SupportFileSP nullptr derefs (#168624) This patch fixes and eliminates the possibility of SupportFileSP ever being nullptr. The support file was originally treated like a value type, but became a polymorphic type and therefore has to be stored and passed around as a pointer. To avoid having all the callers check the validity of the pointer, I introduced the invariant that SupportFileSP is never null and always default constructed. However, without enforcement at the type level, that's fragile and indeed, we already identified two crashes where someone accidentally broke that invariant. This PR introduces a NonNullSharedPtr to prevent that. NonNullSharedPtr is a smart pointer wrapper around std::shared_ptr that guarantees the pointer is never null. If default-constructed, it creates a default-constructed instance of the contained type. Note that I'm using private inheritance because you shouldn't inherit from standard library classes due to the lack of virtual destructor. So while the new abstraction looks like a std::shared_ptr, it is in fact **not** a shared pointer. Given that our destructor is trivial, we could use public inheritance, but currently there's no need for it. rdar://164989579 | 8 个月前 | |
[lldb] Make semantics of SupportFile equivalence explicit (#97126) This is an improved attempt to improve the semantics of SupportFile equivalence, taking into account the feedback from #95606. Pavel's comment about the lack of a concise name because the concept isn't trivial made me realize that I don't want to abstract this concept away behind a helper function. Instead, I opted for a rather verbose enum that forces the caller to consider exactly what kind of comparison is appropriate for every call. | 2 年前 | |
[lldb] Eliminate SupportFileSP nullptr derefs (#168624) This patch fixes and eliminates the possibility of SupportFileSP ever being nullptr. The support file was originally treated like a value type, but became a polymorphic type and therefore has to be stored and passed around as a pointer. To avoid having all the callers check the validity of the pointer, I introduced the invariant that SupportFileSP is never null and always default constructed. However, without enforcement at the type level, that's fragile and indeed, we already identified two crashes where someone accidentally broke that invariant. This PR introduces a NonNullSharedPtr to prevent that. NonNullSharedPtr is a smart pointer wrapper around std::shared_ptr that guarantees the pointer is never null. If default-constructed, it creates a default-constructed instance of the contained type. Note that I'm using private inheritance because you shouldn't inherit from standard library classes due to the lack of virtual destructor. So while the new abstraction looks like a std::shared_ptr, it is in fact **not** a shared pointer. Given that our destructor is trivial, we could use public inheritance, but currently there's no need for it. rdar://164989579 | 8 个月前 | |
[lldb] Teach LLDB about Mach-O filesets This patch teaches LLDB about Mach-O filesets. Filsets are Mach-O files that contain a bunch of other Mach-O files. Unlike universal binaries, which have a different header, Filesets use load commands to describe the different entries it contains. Differential revision: https://reviews.llvm.org/D132433 | 3 年前 | |
[ADT] Prepare to deprecate variadic StringSwitch::Cases. NFC. (#166020) Update all uses of variadic .Cases to use the initializer list overload instead. I plan to mark variadic .Cases as deprecated in a followup PR. For more context, see https://github.com/llvm/llvm-project/pull/163117. | 8 个月前 | |
[lldb] Eliminate namespace lldb_private::dwarf (NFC) (#150073) Eliminate the lldb_private::dwarf namespace, in favor of using llvm::dwarf directly. The latter is shorter, and this avoids ambiguity in the ABI plugins that define a dwarf namespace inside an anonymous namespace. | 1 年前 | |
[LLDB] Fix Memory64 BaseRVA, move all non-stack memory to Mem64. (#146777) ### Context Over a year ago, I landed support for 64b Memory ranges in Minidump (#95312). In this patch we added the Memory64 list stream, which is effectively a Linked List on disk. The layout is a sixteen byte header and then however many Memory descriptors. ### The Bug This is a classic off-by one error, where I added 8 bytes instead of 16 for the header. This caused the first region to start 8 bytes before the correct RVA, thus shifting all memory reads by 8 bytes. We are correctly writing all the regions to disk correctly, with no physical corruption but the RVA is defined wrong, meaning we were incorrectly reading memory  ### Why wasn't this caught? One problem we've had is forcing Minidump to actually use the 64b mode, it would be a massive waste of resources to have a test that actually wrote >4.2gb of IO to validate the 64b regions, and so almost all validation has been manual. As a weakness of manual testing, this issue is psuedo non-deterministic, as what regions end up in 64b or 32b is handled greedily and iterated in the order it's laid out in /proc/pid/maps. We often validated 64b was written correctly by hexdumping the Minidump itself, which was not corrupted (other than the BaseRVA)  ### Why is this showing up now? During internal usage, we had a bug report that the Minidump wasn't displaying values. I was unable to repro the issue, but during my investigation I saw the variables were in the 64b regions which resulted in me identifying the bug. ### How do we prevent future regressions? To prevent regressions, and honestly to save my sanity for figuring out where 8 bytes magically came from, I've added a new API to SBSaveCoreOptions. SBSaveCoreOptions::GetMemoryRegionsToSave() The ability to get the memory regions that we intend to include in the Coredump. I added this so we can compare what we intended to include versus what was actually included. Traditionally we've always had issues comparing regions because Minidump includes /proc/pid/maps and it can be difficult to know what memoryregion read failure was a genuine error or just a page that wasn't meant to be included. We are also leveraging this API to choose the memory regions to be generated, as well as for testing what regions should be bytewise 1:1. After much debate with @clayborg, I've moved all non-stack memory to the Memory64 List. This list doesn't incur us any meaningful overhead and Greg originally suggested doing this in the original 64b PR. This also means we're exercising the 64b path every single time we save a Minidump, preventing regressions on this feature from slipping through testing in the future. Snippet produced by [minidump.py](https://github.com/clayborg/scripts) MINIDUMP_MEMORY_LIST: NumberOfMemoryRanges = 0x00000002 MemoryRanges[0] = [0x00007f61085ff9f0 - 0x00007f6108601000) @ 0x0003f655 MemoryRanges[1] = [0x00007ffe47e50910 - 0x00007ffe47e52000) @ 0x00040c65 MINIDUMP_MEMORY64_LIST: NumberOfMemoryRanges = 0x000000000000002e BaseRva = 0x0000000000042669 MemoryRanges[0] = [0x00005584162d8000 - 0x00005584162d9000) MemoryRanges[1] = [0x00005584162d9000 - 0x00005584162db000) MemoryRanges[2] = [0x00005584162db000 - 0x00005584162dd000) MemoryRanges[3] = [0x00005584162dd000 - 0x00005584162ff000) MemoryRanges[4] = [0x00007f6100000000 - 0x00007f6100021000) MemoryRanges[5] = [0x00007f6108800000 - 0x00007f6108828000) MemoryRanges[6] = [0x00007f6108828000 - 0x00007f610899d000) MemoryRanges[7] = [0x00007f610899d000 - 0x00007f61089f9000) MemoryRanges[8] = [0x00007f61089f9000 - 0x00007f6108a08000) MemoryRanges[9] = [0x00007f6108bf5000 - 0x00007f6108bf7000) ### Misc As a part of this fix I had to look at LLDB logs a lot, you'll notice I added 0x to many of the PRIx64 LLDB_LOGF. This is so the user (or I) can directly copy paste the address in the logs instead of adding the hex prefix themselves. Added some SBSaveCore tests for the new GetMemoryAPI, and Docstrings. CC: @DavidSpickett, @da-viper @labath because we've been working together on save-core plugins, review it optional and I didn't tag you but figured you'd want to know | 1 年前 | |
Re-land LLDB dap module symbol tables (#155021) Re-land the symbol table feature in lldb-dap after it was [reverted](https://github.com/llvm/llvm-project/commit/2b8e80694263fb404d1d0b816f33df731e617625) because of a crash in the aarch64 tests, which was caused by dereferencing SBSymbol::GetName which might return nullptr for an invalid symbol. This patch reapplies the original commits and adds the missing null check. Also adding skipIfWindows for the module symbols tests, since LLDB doesn't recognize the symbols from a.out there. | 11 个月前 | |
[lldb][Format] Introduce new frame-format variables for function parts (#131836) Adds new frame-format variables and implements them in the CPlusPlusLanguage plugin. We use the DemangledNameInfo type to retrieve the necessary part of the demangled name. https://github.com/llvm/llvm-project/pull/131836 | 1 年前 | |
[lldb] Remerge #136236 (Avoid force loading symbols in statistics collection (#136795) Fix a [test failure](https://github.com/llvm/llvm-project/pull/136236#issuecomment-2819772879) in #136236, apply a minor renaming of statistics, and remerge. See details below. # Changes in #136236 Currently, DebuggerStats::ReportStatistics() calls Module::GetSymtab(/*can_create=*/false), but then the latter calls SymbolFile::GetSymtab(). This will load symbols if haven't yet. See stacktrace below. The problem is that DebuggerStats::ReportStatistics should be read-only. This is especially important because it reports stats for symtab parsing/indexing time, which could be affected by the reporting itself if it's not read-only. This patch fixes this problem by adding an optional parameter SymbolFile::GetSymtab(bool can_create = true) and receiving the false value passed down from Module::GetSymtab(/*can_create=*/false) when the call is initiated from DebuggerStats::ReportStatistics(). --- Notes about the following stacktrace: 1. This can be reproduced. Create a helloworld program on **macOS** with dSYM, add settings set target.preload-symbols false to ~/.lldbinit, do lldb a.out, then statistics dump. 2. ObjectFile::GetSymtab has llvm::call_once. So the fact that it called into ObjectFileMachO::ParseSymtab means that the symbol table is actually being parsed. `` (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = step over frame #0: 0x0000000124c4d5a0 LLDBObjectFileMachO::ParseSymtab(this=0x0000000111504e40, symtab=0x0000600000a05e00) at ObjectFileMachO.cpp:2259:44 * frame #1: 0x0000000124fc50a0 LLDBlldb_private::ObjectFile::GetSymtab()::$_0::operator()(this=0x000000016d35c858) const at ObjectFile.cpp:761:9 frame #5: 0x0000000124fc4e68 LLDBvoid std::__1::__call_once_proxy[abi:v160006]<std::__1::tuple<lldb_private::ObjectFile::GetSymtab()::$_0&&>>(__vp=0x000000016d35c7f0) at mutex:652:5 frame #6: 0x0000000198afb99c libc++.1.dylibstd::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 196 frame #7: 0x0000000124fc4dd0 LLDBvoid std::__1::call_once[abi:v160006]<lldb_private::ObjectFile::GetSymtab()::$_0>(__flag=0x0000600003920080, __func=0x000000016d35c858) at mutex:670:9 frame #8: 0x0000000124fc3cb0 LLDBvoid llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=0x0000600003920080, F=0x000000016d35c858) at Threading.h:88:5 frame #9: 0x0000000124fc2bc4 LLDBlldb_private::ObjectFile::GetSymtab(this=0x0000000111504e40) at ObjectFile.cpp:755:5 frame #10: 0x0000000124fe0a28 LLDBlldb_private::SymbolFileCommon::GetSymtab(this=0x0000000104865200) at SymbolFile.cpp:158:39 frame #11: 0x0000000124d8fedc LLDBlldb_private::Module::GetSymtab(this=0x00000001113041a8, can_create=false) at Module.cpp:1027:21 frame #12: 0x0000000125125bdc LLDBlldb_private::DebuggerStats::ReportStatistics(debugger=0x000000014284d400, target=0x0000000115808200, options=0x000000014195d6d1) at Statistics.cpp:329:30 frame #13: 0x0000000125672978 LLDBCommandObjectStatsDump::DoExecute(this=0x000000014195d540, command=0x000000016d35d820, result=0x000000016d35e150) at CommandObjectStats.cpp:144:18 frame #14: 0x0000000124f29b40 LLDBlldb_private::CommandObjectParsed::Execute(this=0x000000014195d540, args_string="", result=0x000000016d35e150) at CommandObject.cpp:832:9 frame #15: 0x0000000124efbd70 LLDBlldb_private::CommandInterpreter::HandleCommand(this=0x0000000141b22f30, command_line="statistics dump", lazy_add_to_history=eLazyBoolCalculate, result=0x000000016d35e150, force_repeat_command=false) at CommandInterpreter.cpp:2134:14 frame #16: 0x0000000124f007f4 LLDBlldb_private::CommandInterpreter::IOHandlerInputComplete(this=0x0000000141b22f30, io_handler=0x00000001419b2aa8, line="statistics dump") at CommandInterpreter.cpp:3251:3 frame #17: 0x0000000124d7b5ec LLDBlldb_private::IOHandlerEditline::Run(this=0x00000001419b2aa8) at IOHandler.cpp:588:22 frame #18: 0x0000000124d1e8fc LLDBlldb_private::Debugger::RunIOHandlers(this=0x000000014284d400) at Debugger.cpp:1225:16 frame #19: 0x0000000124f01f74 LLDBlldb_private::CommandInterpreter::RunCommandInterpreter(this=0x0000000141b22f30, options=0x000000016d35e63c) at CommandInterpreter.cpp:3543:16 frame #20: 0x0000000122840294 LLDBlldb::SBDebugger::RunCommandInterpreter(this=0x000000016d35ebd8, auto_handle_events=true, spawn_thread=false) at SBDebugger.cpp:1212:42 frame #21: 0x0000000102aa6d28 lldbDriver::MainLoop(this=0x000000016d35ebb8) at Driver.cpp:621:18 frame #22: 0x0000000102aa75b0 lldbmain(argc=1, argv=0x000000016d35f548) at Driver.cpp:829:26 frame #23: 0x0000000198858274 dyldstart + 2840 `` # Changes in this PR top of the above Fix a [test failure](https://github.com/llvm/llvm-project/pull/136236#issuecomment-2819772879) in TestStats.py. The original version of the added test checks that all modules have symbol count zero when target.preload-symbols == false`. The test failed on macOS. Due to various reasons, on macOS, symbols can be loaded for dylibs even with that setting, but not for the main module. For now, the fix of the test is to limit the assertion to only the main module. The test now passes on macOS. In the future, when we have a way to control a specific list of plug-ins to be loaded, there may be a configuration that this test can use to assert that all modules have symbol count zero. Apply a minor renaming of statistics, per the [suggestion](https://github.com/llvm/llvm-project/pull/136226#issuecomment-2825080275) in #136226 after merge. | 1 年前 | |
[lldb][TypeSystem] Enable colored AST dump (#86159) This patch causes the various AST dump commands ( target modules dump ast/target dump typesystem) to be color-highlighted. I added a bool show_color parameter to SymbolFile::DumpClangAST and TypeSystem::Dump. In TypeSystemClang I temporarily sets the getShowColors flag on the owned Clang AST (using an RAII helper) for the duration of the AST dump. We use Debugger::GetUseColors to decide whether to color the AST dump. | 10 个月前 | |
[lldb] Expand background symbol download (#80890) LLDB has a setting (symbols.enable-background-lookup) that calls dsymForUUID on a background thread for images as they appear in the current backtrace. Originally, the laziness of only looking up symbols for images in the backtrace only existed to bring the number of dsymForUUID calls down to a manageable number. Users have requesting the same functionality but blocking. This gives them the same user experience as enabling dsymForUUID globally, but without the massive upfront cost of having to download all the images, the majority of which they'll likely not need. This patch renames the setting to have a more generic name (symbols.auto-download) and changes its values from a boolean to an enum. Users can now specify "off", "background" and "foreground". The default remains "off" although I'll probably change that in the near future. | 2 年前 | |
[lldb] Return StringRef from PluginInterface::GetPluginName There is no reason why this function should be returning a ConstString. While modifying these files, I also fixed several instances where GetPluginName and GetPluginNameStatic were returning different strings. I am not changing the return type of GetPluginNameStatic in this patch, as that would necessitate additional changes, and this patch is big enough as it is. Differential Revision: https://reviews.llvm.org/D111877 | 4 年前 | |
[lldb][NFC] use llvm::erase_if to remove non matching types (#168279) | 8 个月前 | |
[lldb][TypeSystem] Remove count parameter from TypeSystem::GetEncoding (#165702) There were a couple of quirks with this parameter: 1. It wasn't being set consistently. E.g., vector types would be of count 1 but complex types would be 2. Hence, it wasn't clear what count was referring to. 2. count was not being set if the input type was invalid, possibly leaving the input reference uninitialized. 3. Only one callsite actually made use of count, and that in itself seems like it could be improved (added a FIXME). If we ever need a "how many elements does this type represent", we can implement one with a new TypeSystem API that does exactly that. | 9 个月前 | |
[lldb] Improve type name parsing (#91586) Parsing of '::' scopes in TypeQuery was very naive and failed for names with '::''s in template arguments. Interestingly, one of the functions it was calling (Type::GetTypeScopeAndBasename) was already doing the same thing, and getting it (mostly (*)) right. This refactors the function so that it can return the scope results, fixing the parsing of names like std::vector<int, std::allocator<int>>::iterator. Two callers of GetTypeScopeAndBasename are deleted as the functions are not used (I presume they stopped being used once we started pruning type search results more eagerly). (*) This implementation is still not correct when one takes c++ operators into account -- e.g., something like X<&A::operator<>::T is a legitimate type name. We do have an implementation that is able to handle names like these (CPlusPlusLanguage::MethodName), but using it is not trivial, because it is hidden in a language plugin and specific to method name parsing. --------- Co-authored-by: Michael Buch <michaelbuch12@gmail.com> | 2 年前 | |
[lldb] Improve type name parsing (#91586) Parsing of '::' scopes in TypeQuery was very naive and failed for names with '::''s in template arguments. Interestingly, one of the functions it was calling (Type::GetTypeScopeAndBasename) was already doing the same thing, and getting it (mostly (*)) right. This refactors the function so that it can return the scope results, fixing the parsing of names like std::vector<int, std::allocator<int>>::iterator. Two callers of GetTypeScopeAndBasename are deleted as the functions are not used (I presume they stopped being used once we started pruning type search results more eagerly). (*) This implementation is still not correct when one takes c++ operators into account -- e.g., something like X<&A::operator<>::T is a legitimate type name. We do have an implementation that is able to handle names like these (CPlusPlusLanguage::MethodName), but using it is not trivial, because it is hidden in a language plugin and specific to method name parsing. --------- Co-authored-by: Michael Buch <michaelbuch12@gmail.com> | 2 年前 | |
[LLDB] Add unary plus and minus to DIL (#155617) This patch adds unary nodes plus and minus, introduces unary type conversions, and adds integral promotion to the type system. | 8 个月前 | |
Reapply "[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#… (#145959) (#146112) Reapply "[NFC][DebugInfo][DWARF] Create new low-level dwarf library (#… (#145959) This reapplies cbf781f0bdf2f680abbe784faedeefd6f84c246e, with fixes for the shared-library build and the unconventional sanitizer-runtime build. Original Description: This is the culmination of a series of changes described in [1]. Although somewhat large by line count, it is almost entirely mechanical, creating a new library in DebugInfo/DWARF/LowLevel. This new library has very minimal dependencies, allowing it to be used from more places than the normal DebugInfo/DWARF library--in particular from MC. 1. https://discourse.llvm.org/t/rfc-debuginfo-dwarf-refactor-into-to-lower-and-higher-level-libraries/86665/2 | 1 年前 | |
[lldb] Parse DWARF CFI for discontinuous functions (#137006) This patch uses the previously build infrastructure to parse multiple FDE entries into a single unwind plan. There is one catch though: we parse only one FDE entry per unwind range. This is not fully correct because lldb coalesces adjecant address ranges, which means that something that originally looked like two separate address ranges (and two FDE entries) may get merged into one because if the linker decides to put the two ranges next to each other. In this case, we will ignore the second FDE entry. It would be more correct to try to parse another entry when the one we found turns out to be short, but I'm not doing this (yet), because: - this is how we've done things so far (although, monolithic functions are unlikely to have more than one FDE entry) - in cases where we don't have debug info or (full) symbol tables, we can end up with "symbols" which appear to span many megabytes (potentially, the whole module). If we tried to fill short FDE entries, we could end up parsing the entire eh_frame section in a single go. In a way, this would be more correct, but it would also probably be very slow. I haven't quite decided what to do about this case yet, though it's not particularly likely to happen in the "production" cases as typically the functions are split into two parts (hot/cold) instead of one part per basic block. | 1 年前 | |
[lldb][nfc] Factor out code checking if Variable is in scope (#143572) This is useful for checking whether a variable is in scope inside a specific block. | 1 年前 | |
[lldb] Replace default bodies of special member functions with = default; Replace default bodies of special member functions with = default; $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix , https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html Differential revision: https://reviews.llvm.org/D104041 | 5 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 10 个月前 | ||
| 6 年前 | ||
| 4 年前 | ||
| 1 年前 | ||
| 8 个月前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 11 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 10 个月前 | ||
| 2 年前 | ||
| 4 年前 | ||
| 8 个月前 | ||
| 9 个月前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 8 个月前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 5 年前 |