aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Symbol/SymbolFile.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-04-24[lldb] Remerge #136236 (Avoid force loading symbols in statistics collection ↵royitaqi1-2/+2
(#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 LLDB`ObjectFileMachO::ParseSymtab(this=0x0000000111504e40, symtab=0x0000600000a05e00) at ObjectFileMachO.cpp:2259:44 * frame #1: 0x0000000124fc50a0 LLDB`lldb_private::ObjectFile::GetSymtab()::$_0::operator()(this=0x000000016d35c858) const at ObjectFile.cpp:761:9 frame #5: 0x0000000124fc4e68 LLDB`void 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.dylib`std::__1::__call_once(unsigned long volatile&, void*, void (*)(void*)) + 196 frame #7: 0x0000000124fc4dd0 LLDB`void std::__1::call_once[abi:v160006]<lldb_private::ObjectFile::GetSymtab()::$_0>(__flag=0x0000600003920080, __func=0x000000016d35c858) at mutex:670:9 frame #8: 0x0000000124fc3cb0 LLDB`void llvm::call_once<lldb_private::ObjectFile::GetSymtab()::$_0>(flag=0x0000600003920080, F=0x000000016d35c858) at Threading.h:88:5 frame #9: 0x0000000124fc2bc4 LLDB`lldb_private::ObjectFile::GetSymtab(this=0x0000000111504e40) at ObjectFile.cpp:755:5 frame #10: 0x0000000124fe0a28 LLDB`lldb_private::SymbolFileCommon::GetSymtab(this=0x0000000104865200) at SymbolFile.cpp:158:39 frame #11: 0x0000000124d8fedc LLDB`lldb_private::Module::GetSymtab(this=0x00000001113041a8, can_create=false) at Module.cpp:1027:21 frame #12: 0x0000000125125bdc LLDB`lldb_private::DebuggerStats::ReportStatistics(debugger=0x000000014284d400, target=0x0000000115808200, options=0x000000014195d6d1) at Statistics.cpp:329:30 frame #13: 0x0000000125672978 LLDB`CommandObjectStatsDump::DoExecute(this=0x000000014195d540, command=0x000000016d35d820, result=0x000000016d35e150) at CommandObjectStats.cpp:144:18 frame #14: 0x0000000124f29b40 LLDB`lldb_private::CommandObjectParsed::Execute(this=0x000000014195d540, args_string="", result=0x000000016d35e150) at CommandObject.cpp:832:9 frame #15: 0x0000000124efbd70 LLDB`lldb_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 LLDB`lldb_private::CommandInterpreter::IOHandlerInputComplete(this=0x0000000141b22f30, io_handler=0x00000001419b2aa8, line="statistics dump") at CommandInterpreter.cpp:3251:3 frame #17: 0x0000000124d7b5ec LLDB`lldb_private::IOHandlerEditline::Run(this=0x00000001419b2aa8) at IOHandler.cpp:588:22 frame #18: 0x0000000124d1e8fc LLDB`lldb_private::Debugger::RunIOHandlers(this=0x000000014284d400) at Debugger.cpp:1225:16 frame #19: 0x0000000124f01f74 LLDB`lldb_private::CommandInterpreter::RunCommandInterpreter(this=0x0000000141b22f30, options=0x000000016d35e63c) at CommandInterpreter.cpp:3543:16 frame #20: 0x0000000122840294 LLDB`lldb::SBDebugger::RunCommandInterpreter(this=0x000000016d35ebd8, auto_handle_events=true, spawn_thread=false) at SBDebugger.cpp:1212:42 frame #21: 0x0000000102aa6d28 lldb`Driver::MainLoop(this=0x000000016d35ebb8) at Driver.cpp:621:18 frame #22: 0x0000000102aa75b0 lldb`main(argc=1, argv=0x000000016d35f548) at Driver.cpp:829:26 frame #23: 0x0000000198858274 dyld`start + 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.
2025-04-21Revert "[lldb] Avoid force loading symbols in statistics collection (#136236)"Shubham Sandeep Rastogi1-2/+2
This reverts commit d5b40c71f6be972f677de5d9886f91866df007b5. This change broke greendragon lldb test: lldb-api :: commands/statistics/basic/TestStats.py And is therefore being reverted.
2025-04-21[lldb] Avoid force loading symbols in statistics collection (#136236)royitaqi1-2/+2
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 receive the `false` value passed down from `Module::GetSymtab(/*can_create=*/false)` when the call was initiated from `DebuggerStats::ReportStatistics()`.
2025-04-04[lldb] Add a {ObjectFile,SymbolFile}::GetObjectName method (#133370)Jonas Devlieghere1-0/+6
Add ObjectFile::GetObjectName and SymbolFile::GetObjectName to retrieve the name of the object file, including the `.a` for static libraries. We currently do something similar in CommandObjectTarget, but the code for dumping this is a lot more involved than what's being offered by the new method. We have options to print he full path, the base name, and the directoy of the path and trim it to a specific width. This is motivated by #133211, where Greg pointed out that the old code would print the static archive (the .a file) rather than the actual object file inside of it.
2024-02-19[Reland] Report only loaded debug info in statistics dump (#81706) (#82207)Wanyi1-1/+1
Updates: - The previous patch changed the default behavior to not load dwos in `DWARFUnit` ~~`SymbolFileDWARFDwo *GetDwoSymbolFile(bool load_all_debug_info = false);`~~ `SymbolFileDWARFDwo *GetDwoSymbolFile(bool load_all_debug_info = true);` - This broke some lldb-shell tests (see https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/16273/) - TestDebugInfoSize.py - with symbol on-demand, by default statistics dump only reports skeleton debug info size - `statistics dump -f` will load all dwos. debug info = skeleton debug info + all dwo debug info Currently running `statistics dump` will trigger lldb to load debug info that's not yet loaded (eg. dwo files). Resulted in a delay in the command return, which, can be interrupting. This patch also added a new option `--load-all-debug-info` asking statistics to dump all possible debug info, which will force loading all debug info available if not yet loaded.
2024-02-17Revert "Report only loaded debug info in statistics dump (#81706)" (#82150)Jonas Devlieghere1-1/+1
This reverts commit 21ddd7ff2b166c5e133b460b1a09ee8adb786ccd because it breaks a bunch of tests: https://lab.llvm.org/buildbot/#/builders/68/builds/69018 https://green.lab.llvm.org/green/view/LLDB/job/as-lldb-cmake/16273
2024-02-17Report only loaded debug info in statistics dump (#81706)Wanyi1-1/+1
Currently running `statistics dump` will trigger lldb to load debug info that's not yet loaded (eg. dwo files). Resulted in a delay in the command return, which, can be interrupting. This patch also added a new option `--load-all-debug-info` asking statistics to dump all possible debug info, which will force loading all debug info available if not yet loaded.
2023-12-12[lldb] Make only one function that needs to be implemented when searching ↵Greg Clayton1-11/+0
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
2023-11-03[lldb][NFC] Use UNUSED_IF_ASSERT_DISABLED instead of (void) castDavid Spickett1-1/+1
Uses of (void) remain where they are for purposes other than an assert variable.
2023-10-12Add `target modules dump separate-debug-info` (#66035)Tom Yang1-0/+1
Add a new command ``` target modules dump separate-debug-info [-j] [<filename> [<filename> [...]]] ``` or ``` image dump separate-debug-info [-j] [<filename> [<filename> [...]]] ``` (since `image` is an alias for `target modules`). This lists the separate debug info files and their current status (loaded or not loaded) for the specified modules. This diff implements this command for mach-O files with OSO and ELF files with dwo. Example dwo: ``` (lldb) image dump separate-debug-info Symbol file: /home/toyang/workspace/dwo-scratch/a.out Type: "dwo" Dwo ID Err Dwo Path ------------------ --- ----------------------------------------- 0x9a429da5abb6faae /home/toyang/workspace/scratch-dwo/a-main.dwo 0xbcc129959e76ff33 /home/toyang/workspace/scratch-dwo/a-foo.dwo (lldb) image dump separate-debug-info -j [ { "separate-debug-info-files": [ { "comp_dir": "/home/toyang/workspace/dwo-scratch", "dwo_id": 11115620165179865774, "dwo_name": "a-main.dwo", "loaded": true, "resolved_dwo_path": "/home/toyang/workspace/dwo-scratch/a-main.dwo" }, { "comp_dir": "/home/toyang/workspace/dwo-scratch", "dwo_id": 13601198072221073203, "dwo_name": "a-foo.dwo", "loaded": true, "resolved_dwo_path": "/home/toyang/workspace/dwo-scratch/a-foo.dwo" } ], "symfile": "/home/toyang/workspace/dwo-scratch/a.out", "type": "dwo" } ] ``` Example dwo with missing dwo: ``` (lldb) image dump separate-debug-info Symbol file: /home/toyang/workspace/dwo-scratch/a.out Type: "dwo" Dwo ID Err Dwo Path ------------------ --- ----------------------------------------- 0x9a429da5abb6faae E unable to locate .dwo debug file "/home/toyang/workspace/scratch-dwo/b.out-main.dwo" for skeleton DIE 0x0000000000000014 0xbcc129959e76ff33 E unable to locate .dwo debug file "/home/toyang/workspace/scratch-dwo/b.out-foo.dwo" for skeleton DIE 0x000000000000003c (lldb) image dump separate-debug-info -j [ { "separate-debug-info-files": [ { "comp_dir": "/home/toyang/workspace/dwo-scratch", "dwo_id": 11115620165179865774, "dwo_name": "a-main.dwo", "error": "unable to locate .dwo debug file \"/home/toyang/workspace/dwo-scratch/a-main.dwo\" for skeleton DIE 0x0000000000000014", "loaded": false }, { "comp_dir": "/home/toyang/workspace/dwo-scratch", "dwo_id": 13601198072221073203, "dwo_name": "a-foo.dwo", "error": "unable to locate .dwo debug file \"/home/toyang/workspace/dwo-scratch/a-foo.dwo\" for skeleton DIE 0x000000000000003c", "loaded": false } ], "symfile": "/home/toyang/workspace/dwo-scratch/a.out", "type": "dwo" } ] ``` Example output with dwp: ``` (lldb) image dump separate-debug-info Symbol file: /home/toyang/workspace/dwo-scratch/a.out Type: "dwo" Dwo ID Err Dwo Path ------------------ --- ----------------------------------------- 0x9a429da5abb6faae /home/toyang/workspace/dwo-scratch/a.out.dwp(a-main.dwo) 0xbcc129959e76ff33 /home/toyang/workspace/dwo-scratch/a.out.dwp(a-foo.dwo) (lldb) image dump separate-debug-info -j [ { "separate-debug-info-files": [ { "comp_dir": "/home/toyang/workspace/dwo-scratch", "dwo_id": 11115620165179865774, "dwo_name": "a-main.dwo", "loaded": true, "resolved_dwo_path": "/home/toyang/workspace/dwo-scratch/a.out.dwp" }, { "comp_dir": "/home/toyang/workspace/dwo-scratch", "dwo_id": 13601198072221073203, "dwo_name": "a-foo.dwo", "loaded": true, "resolved_dwo_path": "/home/toyang/workspace/dwo-scratch/a.out.dwp" } ], "symfile": "/home/toyang/workspace/dwo-scratch/a.out", "type": "dwo" } ] ``` Example oso on my Mac: ``` (lldb) image dump separate-debug-info Symbol file: /Users/toyang/workspace/scratch/a.out Type: "oso" Mod Time Err Oso Path ------------------ --- --------------------- 0x0000000064e64868 /Users/toyang/workspace/scratch/foo.a(foo.o) 0x0000000064e64868 /Users/toyang/workspace/scratch/foo.a(main.o) (lldb) image dump separate-debug-info -j [ { "separate-debug-info-files": [ { "loaded": true, "oso_mod_time": 1692813416, "oso_path": "/Users/toyang/workspace/scratch/foo.a(foo.o)", "so_file": "/Users/toyang/workspace/scratch/foo.cpp" }, { "loaded": true, "oso_mod_time": 1692813416, "oso_path": "/Users/toyang/workspace/scratch/foo.a(main.o)", "so_file": "/Users/toyang/workspace/scratch/main.cpp" } ], "symfile": "/Users/toyang/workspace/scratch/a.out", "type": "oso" } ] ``` Test Plan: Tested on Mac OS and Linux. ``` lldb-dotest -p TestDumpDwo lldb-dotest -p TestDumpOso ``` --------- Co-authored-by: Tom Yang <toyang@fb.com>
2023-01-09[lldb] Fix symbol table use after freeAugusto Noronha1-10/+9
The symbol file stores a raw pointer to the main object file's symbol table. This pointer, however, can be freed, if ObjectFile::ClearSymtab is ever called. This patch makes sure out pointer to the symbol file is valid before using it.
2022-11-16Make CompilerType safeAdrian Prantl1-2/+3
When a process gets restarted TypeSystem objects associated with it may get deleted, and any CompilerType objects holding on to a reference to that type system are a use-after-free in waiting. Because of the SBAPI, we don't have tight control over where CompilerTypes go and when they are used. This is particularly a problem in the Swift plugin, where the scratch TypeSystem can be restarted while the process is still running. The Swift plugin has a lock to prevent abuse, but where there's a lock there can be bugs. This patch changes CompilerType to store a std::weak_ptr<TypeSystem>. Most of the std::weak_ptr<TypeSystem>* uglyness is hidden by introducing a wrapper class CompilerType::WrappedTypeSystem that has a dyn_cast_or_null() method. The only sites that need to know about the weak pointer implementation detail are the ones that deal with creating TypeSystems. rdar://101505232 Differential Revision: https://reviews.llvm.org/D136650
2022-08-04Re-submit "[lldb] Filter DIEs based on qualified name where possible"Alex Langford1-2/+1
This reverts commit 967df65a3610f98a3bc0ec0f2303641d7bad176c. This fixes test/Shell/SymbolFile/NativePDB/find-functions.cpp. When looking up functions with the PDB plugins, if we are looking for a full function name, we should use `GetName` to populate the `name` field instead of `GetLookupName` since `GetName` has the more complete information.
2022-08-04Revert "[lldb] Filter DIEs based on qualified name where possible"Alex Langford1-1/+2
This reverts commit befa77e59a7760d8c4fdd177b234e4a59500f61c. Looks like this broke a SymbolFileNativePDB test. I'll investigate and resubmit with a fix soon.
2022-08-04[lldb] Filter DIEs based on qualified name where possibleAlex Langford1-2/+1
Context: When setting a breakpoint by name, we invoke Module::FindFunctions to find the function(s) in question. However, we use a Module::LookupInfo to first process the user-provided name and figure out exactly what we're looking for. When we actually perform the function lookup, we search for the basename. After performing the search, we then filter out the results using Module::LookupInfo::Prune. For example, given a::b::foo we would first search for all instances of foo and then filter out the results to just names that have a::b::foo in them. As one can imagine, this involves a lot of debug info processing that we do not necessarily need to be doing. Instead of doing one large post-processing step after finding each instance of `foo`, we can filter them as we go to save time. Some numbers: Debugging LLDB and placing a breakpoint on llvm::itanium_demangle::StringView::begin without this change takes approximately 70 seconds and resolves 31,920 DIEs. With this change, placing the breakpoint takes around 30 seconds and resolves 8 DIEs. Differential Revision: https://reviews.llvm.org/D129682
2022-04-26Introduce new symbol on-demand for debug infoJeffrey Tan1-0/+19
This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true" The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand. In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application. Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion In all above situations the module's debug info will be on-demand parsed and indexed. Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed) Differential Revision: https://reviews.llvm.org/D121631
2022-04-25Refactor protected virtual functions from SymbolFile into new ↵Jeffrey Tan1-51/+54
SymbolFileCommon class. This is a preparatory patch for https://reviews.llvm.org/D121631. It refactors protected virtual members of SymbolFile into a new SymbolFileCommon class per suggestion in: https://reviews.llvm.org/D121631 This will avoid the friendship declaration in that patch. Differential Revision: https://reviews.llvm.org/D124110
2021-12-24Remove redundant return and continue statements (NFC)Kazu Hirata1-3/+1
Identified with readability-redundant-control-flow.
2021-12-09[lldb][NFC] clang-format some files as preparation for ↵Lasse Folger1-3/+5
https://reviews.llvm.org/D114627 Reviewed By: werat Differential Revision: https://reviews.llvm.org/D115110
2021-10-26Add new key/value pairs to the module statistics for "statistics dump".Greg Clayton1-0/+12
The new key/value pairs that are added to each module's stats are: "debugInfoByteSize": The size in bytes of debug info for each module. "debugInfoIndexTime": The time in seconds that it took to index the debug info. "debugInfoParseTime": The time in seconds that debug info had to be parsed. At the top level we add up all of the debug info size, parse time and index time with the following keys: "totalDebugInfoByteSize": The size in bytes of all debug info in all modules. "totalDebugInfoIndexTime": The time in seconds that it took to index all debug info if it was indexed for all modules. "totalDebugInfoParseTime": The time in seconds that debug info was parsed for all modules. Differential Revision: https://reviews.llvm.org/D112501
2021-05-04[lldb] Refactor argument group by SourceLocationSpec (NFCI)Med Ismail Bennani1-4/+4
This patch refactors a good part of the code base turning the usual FileSpec, Line, Column, CheckInlines, ExactMatch arguments into a SourceLocationSpec object. This change is required for a following patch that will add handling of the column line information when doing symbol resolution. Differential Revision: https://reviews.llvm.org/D100965 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-02-18[lldb][NFC] Make all CompilerDeclContext parameters references instead of ↵Raphael Isemann1-3/+3
pointers Summary: All of our lookup APIs either use `CompilerDeclContext &` or `CompilerDeclContext *` semi-randomly it seems. This leads to us constantly converting between those two types (and doing nullptr checks when going from pointer to reference). It also leads to the confusing situation where we have two possible ways to express that we don't have a CompilerDeclContex: either a nullptr or an invalid CompilerDeclContext (aka a default constructed CompilerDeclContext). This moves all APIs to use references and gets rid of all the nullptr checks and conversions. Reviewers: labath, mib, shafik Reviewed By: labath, shafik Subscribers: shafik, arphaman, abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D74607
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann1-1/+1
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
2019-11-15Add RTTI support to the SymbolFile class hierarchyAdrian Prantl1-0/+2
Differential Revision: https://reviews.llvm.org/D70322
2019-11-12Performance: Add a set of visited SymbolFiles to the other FindFiles variant.Adrian Prantl1-1/+3
This is basically the same bug as in r260434. SymbolFileDWARF::FindTypes has exponential worst-case when digging through dependency DAG of .pcm files because each object file and .pcm file may depend on an already-visited .pcm file, which may again have dependencies. Fixed here by carrying a set of already visited SymbolFiles around. rdar://problem/56993424 Differential Revision: https://reviews.llvm.org/D70106
2019-10-17Modernize the rest of the Find.* API (NFC)Adrian Prantl1-30/+18
This patch removes the size_t return value and the append parameter from the remainder of the Find.* functions in LLDB's internal API. As in the previous patches, this is motivated by the fact that these parameters aren't really used, and in the case of the append parameter were frequently implemented incorrectly. Differential Revision: https://reviews.llvm.org/D69119 llvm-svn: 375160
2019-10-01Remove size_t return parameter from FindTypesAdrian Prantl1-8/+4
In r368345 I accidentally introduced a regression that would over-report the number of matches found by FindTypes if the DeclContext Filter was hit. This patch simply removes the size_t return parameter altogether — it's not that useful. rdar://problem/55500457 Differential Revision: https://reviews.llvm.org/D68169 llvm-svn: 373344
2019-09-30Remove unused "append" parameter from FindTypes APIAdrian Prantl1-7/+2
I noticed that SymbolFileDWARFDebugMap::FindTypes was implementing it incorrectly (passing append=false in a for-loop to recursive calls to FindTypes would yield only the very last set of results), but instead of fixing it, removing it seemed like an even better option. rdar://problem/54412692 Differential Revision: https://reviews.llvm.org/D68171 llvm-svn: 373224
2019-08-22Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl1-1/+2
This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> This reapplies r369690 with a previously missing constructor for LanguageSet. llvm-svn: 369710
2019-08-22Revert Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl1-2/+1
This reverts r369690 (git commit aa3a564efa6b5fff2129f81a4041069a0233168f) llvm-svn: 369702
2019-08-22Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl1-1/+2
This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> llvm-svn: 369690
2019-08-21Generalize FindTypes with CompilerContext to support fuzzy lookupAdrian Prantl1-1/+1
This patch generalizes the FindTypes with CompilerContext interface to support looking up a type of unknown kind by name, as well as looking up a type inside an unspecified submodule. These features are motivated by the Swift branch, but are fully tested via unit tests and lldb-test on llvm.org. Specifically, this patch adds an AnyModule and an AnyType CompilerContext kind. Differential Revision: https://reviews.llvm.org/D66507 rdar://problem/54471165 llvm-svn: 369555
2019-08-05Fix PDB tests after r367820Pavel Labath1-0/+2
The commit changed Module dumping code to call SymbolFile::Dump directly, which meant that we were no longer showing the plugin name in the output (as that was done in the SymbolVendor). This adds the plugin name printing code to the SymbolFile dump method, and tweak the assertions in the PDB tests to match it correctly. llvm-svn: 367835
2019-08-05Remove SymbolVendor::GetSymtabPavel Labath1-0/+3
Summary: This patch removes the GetSymtab method from the SymbolVendor, which is a no-op as it's implementation just forwards to the relevant SymbolFile. Instead it creates a Module::GetSymtab, which calls the SymbolFile method directly. All callers have been updated to use the Module method directly instead of a two phase GetSymbolVendor->GetSymtab search, which leads to reduced intentation in a lot of deeply nested code. Reviewers: clayborg, JDevlieghere, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65569 llvm-svn: 367820
2019-07-31SymbolVendor: Remove the object file member variablePavel Labath1-9/+9
Summary: The last responsibility of the SymbolVendor was to hold an owning reference to the object file (in case symbols are being read from a different file than the main module). As SymbolFile classes already hold a non-owning reference to the object file, we can easily remove this responsibility of the SymbolVendor by making the SymbolFile reference owning. Reviewers: JDevlieghere, clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65401 llvm-svn: 367392
2019-07-30[Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford1-5/+7
Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 llvm-svn: 367360
2019-07-30SymbolVendor: Move locking into the Symbol FilesPavel Labath1-0/+1
Summary: The last bit of functionality in SymbolVendor passthrough functions is the locking the module mutex. While it may be nice doing the locking in a central place, we weren't really succesful in doing that right now, because some SymbolFile function could still be called without going through the SymbolVendor. This meant in SymbolFileDWARF (the only battle-tested symbol file implementation) roughly a half of the functions was taking additional locks and another half was asserting that the lock is already held. By making the SymbolFile responsible for locking, we can at least make the situation in SymbolFileDWARF more consistent. Reviewers: clayborg, JDevlieghere, jingham, jdoerfert Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D65329 llvm-svn: 367298
2019-07-29SymbolVendor: Make SectionAddressesChanged a passthroughPavel Labath1-1/+13
Summary: This moves the implementation of the function into the SymbolFile class, making it possible to excise the SymbolVendor passthrough functions in follow-up patches. Reviewers: clayborg, jingham, JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65266 llvm-svn: 367231
2019-07-26SymbolVendor: Move Symtab construction into the SymbolFilePavel Labath1-0/+15
Summary: Instead of having SymbolVendor coordinate Symtab construction between Symbol and Object files, make the SymbolVendor function a passthrough, and put all of the logic into the SymbolFile. Reviewers: clayborg, JDevlieghere, jingham, espindola Subscribers: emaste, mgorny, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D65208 llvm-svn: 367086
2019-07-25SymbolFile: Fix -Wunused-variable in -DLLVM_ENABLE_ASSERTIONS=off builds ↵Fangrui Song1-0/+1
after D65089/r366791 llvm-svn: 367001
2019-07-25SymbolVendor: Remove the type list memberPavel Labath1-6/+4
Summary: Similarly to the compile unit lists, the list of types can also be managed by the symbol file itself. Since the only purpose of this list seems to be to maintain an owning reference to all the types a symbol file has created (items are only ever added to the list, never retrieved), I remove the passthrough functions in SymbolVendor and Module. I also tighten the interface of the function (return a reference instead of a pointer, make it protected instead of public). Reviewers: clayborg, JDevlieghere, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65135 llvm-svn: 366994
2019-07-23SymbolVendor: Move compile unit handling into the SymbolFile classPavel Labath1-0/+48
Summary: SymbolFile classes are responsible for creating CompileUnit instances and they already need to have a notion of the id<->CompileUnit mapping (because of APIs like ParseCompileUnitAtIndex). However, the SymbolVendor has remained as the thing responsible for caching created units (which the SymbolFiles were calling via convoluted constructs like "m_obj_file->GetModule()->GetSymbolVendor()->SetCompileUnitAtIndex(...)"). This patch moves the responsibility of caching the units into the SymbolFile class. It does this by moving the implementation of SymbolVendor::{GetNumCompileUnits,GetCompileUnitAtIndex} into the equivalent SymbolFile functions. The SymbolVendor functions become just a passthrough much like the rest of SymbolVendor. The original implementations of SymbolFile::GetNumCompileUnits is moved to "CalculateNumCompileUnits", and are made protected, as the "Get" function is the external api of the class. SymbolFile::ParseCompileUnitAtIndex is made protected for the same reason. This is the first step in removing the SymbolVendor indirection, as proposed in <http://lists.llvm.org/pipermail/lldb-dev/2019-June/015071.html>. After removing all interesting logic from the SymbolVendor class, I'll proceed with removing the indirection itself. Reviewers: clayborg, jingham, JDevlieghere Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65089 llvm-svn: 366791
2019-05-10FuncUnwinders: Add a new "SymbolFile" unwind planPavel Labath1-0/+2
Summary: some unwind formats are specific to a single symbol file and so it does not make sense for their parsing code live in the general Symbol library (as is the case with eh_frame for instance). This is the case for the unwind information in breakpad files, but the same will probably be true for PDB unwind info (once we are able to parse that). This patch adds the ability to fetch an unwind plan provided by a symbol file plugin, as discussed in the RFC at <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>. I've kept the set of changes to a minimum, as there is no way to test them until we have a symbol file which implements this API -- that is comming in a follow-up patch, which will also implicitly test this change. The interesting part here is the introduction of the "RegisterInfoResolver" interface. The reason for this is that breakpad needs to be able to resolve register names (which are present as strings in the file) into register enums so that it can construct the unwind plan. This is normally done via the RegisterContext class, handing this over to the SymbolFile plugin would mean that it has full access to the debugged process, which is not something we want it to have. So instead, I create a facade, which only provides the ability to query register names, and hide the RegisterContext behind the facade. Also note that this only adds the ability to dump the unwind plan created by the symbol file plugin -- the plan is not used for unwinding yet -- this will be added in a third patch, which will add additional tests which makes sure the unwinding works as a whole. Reviewers: jasonmolenda, clayborg Subscribers: markmentovai, amccarth, lldb-commits Differential Revision: https://reviews.llvm.org/D61732 llvm-svn: 360409
2019-03-06Pass ConstString by value (NFC)Adrian Prantl1-3/+3
My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
2019-02-13Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere1-8/+8
The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
2019-02-12Remove redundant ::get() for smart pointer. (NFC)Jonas Devlieghere1-2/+2
This commit removes redundant calls to smart pointer’s ::get() method. https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html llvm-svn: 353795
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-14[SymbolFile] Remove SymbolContext parameter from FindTypes.Zachary Turner1-3/+2
This parameter was only ever used with the Module set, and since a SymbolFile is tied to a module, the parameter turns out to be entirely unnecessary. Furthermore, it doesn't make a lot of sense to ask a caller to ask SymbolFile which is tied to Module X to find types for Module Y, but that possibility was open with the previous interface. By removing this parameter from the API, it makes it harder to use incorrectly as well as easier for an implementor to understand what it needs to do. llvm-svn: 351133
2018-10-25Don't type-erase the FunctionNameType or TypeClass enums.Zachary Turner1-1/+1
This is similar to D53597, but following up with 2 more enums. After this, all flag enums should be strongly typed all the way through to the symbol files plugins. Differential Revision: https://reviews.llvm.org/D53616 llvm-svn: 345314
2018-10-25Don't type-erase the SymbolContextItem enumeration.Zachary Turner1-1/+1
When we get the `resolve_scope` parameter from the SB API, it's a `uint32_t`. We then pass it through all of LLDB this way, as a uint32. This is unfortunate, because it means the user of an API never actually knows what they're dealing with. We can call it something like `resolve_scope` and have comments saying "this is a value from the `SymbolContextItem` enumeration, but it makes more sense to just have it actually *be* the correct type in the actual C++ type system to begin with. This way the person reading the code just knows what it is. The reason to use integers instead of enumerations for flags is because when you do bitwise operations on enumerations they get promoted to integers, so it makes it tedious to constantly be casting them back to the enumeration types, so I've introduced a macro to make this happen magically. By writing LLDB_MARK_AS_BITMASK_ENUM after defining an enumeration, it will define overloaded operators so that the returned type will be the original enum. This should address all the mechanical issues surrounding using rich enum types directly. This way, we get a better debugger experience, and new users to the codebase can get more easily acquainted with the codebase because their IDE features can help them understand what the types mean. Differential Revision: https://reviews.llvm.org/D53597 llvm-svn: 345313
generated by cgit v1.1 at 2025-08-03 16:53:27 +0000