aboutsummaryrefslogtreecommitdiff
path: root/lldb
AgeCommit message (Collapse)AuthorFilesLines
2024-01-23[lldb] Improve maintainability and readability for ValueObject methods (#75865)Pete Lawrence1-166/+164
As I worked through changes to another PR (https://github.com/llvm/llvm-project/pull/74912), I couldn't help but rewrite a few methods for readability, maintainability, and possibly some behavior correctness too. 1. Exiting early instead of nested `if`-statements, which: - Reduces indentation levels for all subsequent lines - Treats missing pre-conditions similar to an error - Clearly indicates that the full length of the method is the "happy path". 2. Explicitly return empty Value Object shared pointers for those error (like) situations, which - Reduces the time it takes a maintainer to figure out what the method actually returns based on those conditions. 3. Converting a mix of `if` and `if`-`else`-statements around an enum into one `switch` statement, which: - Consolidates the former branching logic - Lets the compiler warn you of a (future) missing enum case - This one may actually change behavior slightly, because what was an early test for one enum case, now happens later on in the `switch`. 4. Consolidating near-identical, "copy-pasta" logic into one place, which: - Separates the common code to the diverging paths. - Highlights the differences between the code paths. rdar://119833526
2024-01-23[lldb][NFCI] Remove unused method BreakpointIDList::AddBreakpointID(const ↵Alex Langford2-11/+0
char *) (#79189) This overload is completely unused.
2024-01-23[lldb] Include SBFormat.h in LLDB.h (#79194)Alex Langford1-0/+1
This was likely overlooked when SBFormat was added.
2024-01-22[lldb][libc++] Adds system_clock data formatters. (#78609)Mark de Wever5-2/+252
2024-01-22Added settings for DEBUGINFOD cache location and timeout (#78605)Kevin Frei2-18/+73
I've been working on more/better configuration for improving DEBUGINFOD support. This is the first (and easiest) slice of the work. I've added `timeout` and `cache-path` settings that can override the DEBUGINFOD library defaults (and environment variables.) I also renamed the `plugin.symbol-locator.debuginfod.server_urls` setting to `server-urls` to be more consistent with the rest of LLDB's settings (the underscore switch is switched to a hyphen) I've got a few tests that validate the cache-path setting (as a side-effect), but they've exposed a few bugs that I'll be putting up a separate PR for (which will include the tests). --------- Co-authored-by: Kevin Frei <freik@meta.com>
2024-01-22[lldb][NFCI] Remove EventData* param from BroadcastEvent (#78773)Alex Langford12-68/+66
BroadcastEvent currently takes its EventData* param and shoves it into an Event object, which takes ownership of the pointer and places it into a shared_ptr to manage the lifetime. Instead of relying on `new` and passing raw pointers around, I think it would make more sense to create the shared_ptr up front.
2024-01-22[lldb] refactor highlighting function for image lookup command (#76112)José Lira Junior9-100/+89
Follow-up to #69422. This PR puts all the highlighting settings into a single struct for easier handling Co-authored-by: Talha Tahir <talha.tahir@10xengineers.ai>
2024-01-21[lldb] Skip ObjC timezone tests on macOS >= 14 (NFC) (#78817)Dave Lee1-10/+16
Starting with macOS 14, the `NSTimeZone` and `CFTimeZone` types are backed by swift implementations. These tests won't pass on mainline lldb, since it doesn't have Swift support.
2024-01-21[c++20] P1907R1: Support for generalized non-type template arguments of ↵Andrey Ali Khan Bolshakov2-0/+4
scalar type. (#78041) Previously committed as 9e08e51a20d0d2b1c5724bb17e969d036fced4cd, and reverted because a dependency commit was reverted, then committed again as 4b574008aef5a7235c1f894ab065fe300d26e786 and reverted again because "dependency commit" 5a391d38ac6c561ba908334d427f26124ed9132e was reverted. But it doesn't seem that 5a391d38ac6c was a real dependency for this. This commit incorporates 4b574008aef5a7235c1f894ab065fe300d26e786 and 18e093faf726d15f210ab4917142beec51848258 by Richard Smith (@zygoloid), with some minor fixes, most notably: - `UncommonValue` renamed to `StructuralValue` - `VK_PRValue` instead of `VK_RValue` as default kind in lvalue and member pointer handling branch in `BuildExpressionFromNonTypeTemplateArgumentValue`; - handling of `StructuralValue` in `IsTypeDeclaredInsideVisitor`; - filling in `SugaredConverted` along with `CanonicalConverted` parameter in `Sema::CheckTemplateArgument`; - minor cleanup in `TemplateInstantiator::transformNonTypeTemplateParmRef`; - `TemplateArgument` constructors refactored; - `ODRHash` calculation for `UncommonValue`; - USR generation for `UncommonValue`; - more correct MS compatibility mangling algorithm (tested on MSVC ver. 19.35; toolset ver. 143); - IR emitting fixed on using a subobject as a template argument when the corresponding template parameter is used in an lvalue context; - `noundef` attribute and opaque pointers in `template-arguments` test; - analysis for C++17 mode is turned off for templates in `warn-bool-conversion` test; in C++17 and C++20 mode, array reference used as a template argument of pointer type produces template argument of UncommonValue type, and `BuildExpressionFromNonTypeTemplateArgumentValue` makes `OpaqueValueExpr` for it, and `DiagnoseAlwaysNonNullPointer` cannot see through it; despite of "These cases should not warn" comment, I'm not sure about correct behavior; I'd expect a suggestion to replace `if` by `if constexpr`; - `temp.arg.nontype/p1.cpp` and `dr18xx.cpp` tests fixed.
2024-01-19Skip TestThreadLocal.py on darwin temporarily for linker issueJason Molenda1-0/+1
The new static linker in Xcode 15 does not emit the necessary symbols for file static thread local storage, causing this test to fail when used. The old static linker is still available as ld-classic in Xcode 15, but it has to be invoked specially, and the new static linker will be fixed at some point. I may try to add linker name and versioning information in lldb/packages/Python/lldbsuite/test/decorators.py like we do with the compiler / compiler_version, so it can be xfailed for known problematic static linker name / versions, but until I get that sorted I'm skipping this test to unblock the CI bots.
2024-01-19[lldb][DWARFUnit] Implement PeekDIEName query (#78486)Felipe de Azevedo Piovezan7-10/+143
This allows us to query the AT_Name of a DIE without parsing the entire CU. Part of the ongoing effort to support IDX_Parent in accelerator tables [1]. [1]: https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/44
2024-01-20[lldb] Fix build error in lldb-dap.cpp (NFC)Jie Fu1-1/+1
llvm-project/lldb/tools/lldb-dap/lldb-dap.cpp:679:5: error: unknown type name 'kkkk' kkkk response["success"] = false; ^
2024-01-19[lldb-dap] Add a CMake variable for defining a welcome message (#78811)Walter Erquinigo2-4/+22
lldb-dap instances managed by other extensions benefit from having a welcome message with, for example, a basic user guide or a troubleshooting message. This PR adds a cmake variable for defining such message in a simple way. This message appears upon initialization but before initCommands are executed, as they might cause a failure and prevent the message from being displayed.
2024-01-19[lldb][test] Apply @expectedFailureAll/@skipIf early for debug_info tests ↵Jordan Rupprecht3-6/+179
(#73067) The @expectedFailureAll and @skipIf decorators will mark the test case as xfail/skip if _all_ conditions passed in match, including debug_info. * If debug_info is not one of the matching conditions, we can immediately evaluate the check and decide if it should be decorated. * If debug_info *is* present as a match condition, we need to defer whether or not to decorate until when the `LLDBTestCaseFactory` metaclass expands the test case into its potential variants. This is still early enough that the standard `unittest` framework will recognize the test as xfail/skip by the time the test actually runs. TestDecorators exhibits the edge cases more thoroughly. With the exception of `@expectedFailureIf` (added by this commit), all those test cases pass prior to this commit. This is a followup to 212a60ec37322f853e91e171b305479b1abff2f2.
2024-01-18Clean up PlatformDarwinKernel::GetSharedModule, document (#78652)Jason Molenda2-43/+49
PlatformDarwinKernel::GetSharedModule, which can find a kernel or kext from a local filesystem scan, needed a little cleanup. The method which finds kernels was (1) not looking for the SymbolFileSpec when creating a Module, and (2) adding that newly created Module to a Target, which GetSharedModule should not be doing - after auditing many other subclass implementations of this method, I haven't found any others doing it. Platform::GetSharedModule didn't have a headerdoc so it took a little work to piece together the intended behaviors. This is addressing a bug where PlatformDarwinKernel::GetSharedModuleKernel would find the ObjectFile for a kernel, create a Module, and add it to the Target. Then up in DynamicLoaderDarwinKernel, it would check if the Module had a SymbolFile FileSpec, and because it did not, it would do its own search for a binary & dSYM, find them, and then add that to the Target. Now we have two copies of the Module in the Target, one with a dSYM and the other without, and only one of them has its load addresses set. GetSharedModule should not be adding binaries to the Target, and it should set the SymbolFile FileSpec when it is creating the Module. rdar://120895951
2024-01-18Revert "[BOLT] Fix unconditional output of boltedcollection in merge-fdata ↵Amir Ayupov4-27/+0
(#78653)" This reverts commit 82bc33ea3f1a539be50ed46919dc53fc6b685da9. Accidentally pushed unrelated changes.
2024-01-18[BOLT] Fix unconditional output of boltedcollection in merge-fdata (#78653)Amir Ayupov4-0/+27
Fix the bug where merge-fdata unconditionally outputs boltedcollection line, regardless of whether input files have it set. Test Plan: Added bolt/test/X86/merge-fdata-nobat-mode.test which fails without this fix.
2024-01-18[lldb] Stop creating BreakpointEventData raw pointers (#78508)Alex Langford2-31/+24
The lifetime of these BreakpointEventData objects is difficult to reason about. These BreakpointEventData pointers are created and passed along to `Event` which takes the raw pointer and sticks them in a shared pointer. Instead of manually managing the lifetime and memory, it would be simpler to have them be shared pointers from the start.
2024-01-18[lldb] Remove redundant severity substring within a diagnostic message. (#76111)Pete Lawrence2-4/+13
For example, the following message has the severity string "error: " twice. > "error: <EXPR>:3:1: error: cannot find 'bogus' in scope This method already appends the severity string in the beginning, but with this fix, it also removes a secondary instance, if applicable. Note that this change only removes the *first* redundant substring. I considered putting the removal logic in a loop, but I decided that if something is generating more than one redundant severity substring, then that's a problem the message's source should probably fix. rdar://114203423
2024-01-18Revert "[lldb] Silence narrowing conversion warning with MSVC"Alexandre Ganea1-1/+1
This reverts commit cb67dc19256565d15f6bed0e9808f4026ca04995.
2024-01-18[lldb] Silence narrowing conversion warning with MSVCAlexandre Ganea1-1/+1
Fixes: ``` [13/270] Building CXX object tools\lldb\unittests\Core\CMakeFiles\LLDBCoreTests.dir\DumpDataExtractorTest.cpp.obj C:\git\llvm-project\lldb\unittests\Core\DumpDataExtractorTest.cpp(140): warning C4305: 'argument': truncation from 'double' to 'const std::complex<float>::_Ty' ```
2024-01-18[lldb] Silence warning with latest MSVCAlexandre Ganea1-0/+1
Fixes several of these: ``` [3370/3822] Building CXX object tools\lldb\source\Plugins\Process\U...lldbPluginProcessUtility.dir\NativeRegisterContextDBReg_x86.cpp.ob C:\git\llvm-project\lldb\source\Plugins\Process\Utility\NativeRegisterContextDBReg_x86.h(23): warning C4589: Constructor of abstract class 'lldb_private::NativeRegisterContextDBReg_x86' ignores initializer for virtual base class 'lldb_private::NativeRegisterContextRegisterInfo' C:\git\llvm-project\lldb\source\Plugins\Process\Utility\NativeRegisterContextDBReg_x86.h(23): note: virtual base classes are only initialized by the most-derived type ```
2024-01-18[lldb] Silence warning with latest MSVC on WindowsAlexandre Ganea1-0/+1
Fixes: ``` [3465/3822] Building CXX object tools\lldb\source\Plugins\SymbolFile\CTF\CMakeFiles\lldbPluginSymbolFileCTF.dir\SymbolFileCTF.cpp.obj C:\git\llvm-project\lldb\source\Plugins\SymbolFile\CTF\SymbolFileCTF.cpp(606) : warning C4715: 'lldb_private::SymbolFileCTF::CreateType': not all control paths return a value ```
2024-01-18[lldb] Silence warning when building with latest MSVCAlexandre Ganea1-1/+1
Fixes: ``` C:\git\llvm-project\lldb\unittests\Core\DumpDataExtractorTest.cpp(140): warning C4305: 'argument': truncation from 'double' to 'const std::complex<float>::_Ty' ```
2024-01-18[lldb] Correct function names in ProcessGDBRemote::ParseFlagsFields log messagesDavid Spickett1-29/+33
This has to be specified in the string because otherwise we'd get the lambda's name, and I incorrectly used the name of the calling function here.
2024-01-18[lldb][Format] Fix missing inlined function names in frame formatting. (#78494)Zequan Wu5-49/+80
This fixes missing inlined function names when formatting frame and the `Block` in `SymbolContext` is a lexical block (e.g. `DW_TAG_lexical_block` in Dwarf).
2024-01-17[lldb] Support changes to TLS on macOS (#77988)Alex Langford1-64/+94
The TLS implementation on apple platforms has changed. Instead of invoking pthread_getspecific with a pthread_key_t, we instead perform a virtual function call. Note: Some versions of Apple's new linker do not emit debug symbols for TLS symbols. This causes the TLS tests to fail because LLDB and dsymutil expects there to be debug symbols to resolve the relevant TLS block. You may work around this by switching to the older linker (ld-classic) or by disabling the TLS tests until you have a newer version of the new linker. rdar://120676969
2024-01-17[lldb] Upstream xros support in lldb (#78389)Jonas Devlieghere21-9/+340
Upstream support for debugging xros applications through LLDB.
2024-01-17[lldb-dap] Adjusting how repl-mode auto determines commands vs variable ↵John Harrison5-57/+75
expressions. (#78005) The previous logic for determining if an expression was a command or variable expression in the repl would incorrectly identify the context in many common cases where a local variable name partially overlaps with the repl input. For example: ``` int foo() { int var = 1; // break point, evaluating "p var", previously emitted a warning } ``` Instead of checking potentially multiple conflicting values against the expression input, I updated the heuristic to only consider the first term. This is much more reliable at eliminating false positives when the input does not actually hide a local variable. Additionally, I updated the warning on conflicts to occur anytime the conflict is detected since the specific conflict can change based on the current input. This also includes additional details on how users can change the behavior. Example Debug Console output from lldb/test/API/tools/lldb-dap/evaluate/main.cpp:11 breakpoint 3. ``` lldb-dap> var + 3 Warning: Expression 'var' is both an LLDB command and variable. It will be evaluated as a variable. To evaluate the expression as an LLDB command, use '`' as a prefix. 45 lldb-dap> var + 1 Warning: Expression 'var' is both an LLDB command and variable. It will be evaluated as a variable. To evaluate the expression as an LLDB command, use '`' as a prefix. 43 ```
2024-01-17[lldb] On Windows, silence warning with latest MSVCAlexandre Ganea1-0/+1
This fixes: ``` [6083/7449] Building CXX object tools\lldb\source\Commands\CMakeFiles\lldbCommands.dir\CommandObjectFrame.cpp.obj C:\git\llvm-project\lldb\source\Commands\CommandObjectFrame.cpp(497) : warning C4715: 'CommandObjectFrameVariable::ScopeRequested': not all control paths return a value ```
2024-01-17[lldb] Silence warning with Clang ToTAlexandre Ganea1-17/+6
This fixes `-Wcovered-switch-default` warnings. This is a reminiscent of an old refactoring, see ce03a862372a6f36d2fcf80dc80052aa155fcae8.
2024-01-17[lldb] Use `LLVM_FALLTHROUGH` to avoid a compiler error when building with MSVC.Alexandre Ganea1-3/+3
2024-01-17[lldb] Replace deprecated `std::unique_ptr::unique()` to silence a warning ↵Alexandre Ganea5-6/+6
with MS-STL. NFC. MS-STL warns about this with `warning STL4016: std::shared_ptr::unique() is deprecated in C++17`.
2024-01-17[lldb] Silence warning when building with Clang ToTAlexandre Ganea1-0/+1
Fixes: ``` C:\git\llvm-project\lldb\source\Plugins\Process\Windows\Common\x64\RegisterContextWindows_x64.cpp(195,5): warning: missing field 'flags_type' initializer [-Wmissing-field-initializers] ```
2024-01-17[lldb] Skip TestExecutableFirst.test_executable_is_first_before_run on ELFPavel Labath1-0/+3
ELF does not have a hard distinction between shared libraries (and position-independent) executables. It is possible to create a shared library that will also be executable.
2024-01-16Return high address masks correctly in Process (#78379)Jason Molenda1-0/+4
In https://reviews.llvm.org/D151292 I added the ability to track address masks separately for high and low memory addresses, a capability of AArch64. I did my testing with manual address mask settings (via target.process.highmem-virtual-addressable-bits) but didn't have a real corefile that included this metadata and required it. My intention is that when the high address mask isn't specified, by the user (via the setting) or the Process plugin, we fall back to using the low address mask. The low and high address mask is the same for almost all environments. But the patch I wrote never uses the Process plugin high address mask if it was set, e.g. from corefile metadata. This patch corrects that. I also have an old patch in Phabractor that was approved to add FixAddress methods to SBProcess; I need to pick that patch up and finish it (I wanted to add an enum to specify which mask is being requested iirc), so I can do address masks tests in API tests. rdar://120926000
2024-01-16[lldb] Fix trailing whitespace & formatting in Core/Module.cpp (NFC)Jonas Devlieghere1-8/+8
I have my editor configured to remove trailing whitespace and every time I touch this file I end up with a bunch of clang-format changes to lines that were modified because of it. Nobody likes trailing whitespace so this cleans up the file.
2024-01-16[lldb] Store SupportFile in CompileUnit (NFC)Jonas Devlieghere6-26/+36
Store a SupportFile, rather than a FileSpec, in CompileUnit. This commit works towards having the SourceManager operate on SupportFiles so that it can (1) validate the Checksum and (2) materialize the content of inline source information.
2024-01-16[lldb] Store SupportFile in LineEntry (NFC) (#77999)Jonas Devlieghere12-29/+40
Store a SupportFile, rather than a FileSpec, in LineEntry. This commit works towards having the SourceManageroperate on SupportFiles so that it can (1) validate the Checksum and (2) materialize the content of inline source information.
2024-01-16Add the Linux "you can use this binary" bits to run_to_source_breakpoint ↵jimingham1-1/+2
(#78377) Follow-on to a4cd99ea8736eda2b8b4de34453f55008bcf9c30 - I forgot you have to add ANY shared library you want to use to extra_images...
2024-01-16Ensure that the executable module is ModuleList[0] (#78360)jimingham5-1/+84
We claim in a couple places that the zeroth element of the module list for a target is the main executable, but we don't actually enforce that in the ModuleList class. As we saw, for instance, in 32dd5b20973bde1ef77fa3b84b9f85788a1a303a it's not all that hard to get this to be off. This patch ensures that the first object file of type Executable added to it is moved to the front of the ModuleList. I also added a test for this. In the normal course of operation, where the executable is added first, this only adds a check for whether the first element in the module list is an executable. If that's true, we just append as normal. Note, the code in Target::GetExecutableModule doesn't actually agree that the zeroth element must be the executable, it instead returns the first Module of type Executable. But I can't tell whether that was a change in intention or just working around the bug that we don't always maintain this ordering. But given we've said this in scripting as well as internally, I think we shouldn't change our minds about this.
2024-01-16[lldb] Remove unused LineEntry ctor (NFC)Jonas Devlieghere2-19/+0
2024-01-16[lldb] Build the TestRosetta.py executable with system stdlib (#78370)Alex Langford1-0/+2
This is a speculative fix for TestRosetta.py which is currently failing on Green Dragon. TestRosetta just makes sure we can debug an x86_64 process on Apple Silicon. However, we're failing to build the x86_64 test binary. The linker is failing with some warnings about libc++ and libunwind being build for arm64 while the target binary is x86_64. I'm going to try building with the system standard libraries instead of the just-built ones to workaround it.
2024-01-16[lldb] Store SupportFile as shared_ptr (NFC)Jonas Devlieghere2-5/+13
2024-01-16[lldb][Progress] Fix test for trimmed progress reports (#78357)Chelsea Cassanova1-8/+3
The test TestTrimmedProgressReporting tests that progress reports are being sent by listening for events with the titles of specific progress reports. Commit f1ef910b removed the report for Apple DWARF indices which was one of the reports being listened for in this test, so that report is removed here as well. That commit also now creates all progress reports with details so reports string are prepended with the details count. This changes the length of the trimmed progress report title string that's checked for here so this commit changes the string to match as well. This test was skipped on non-Apple platforms, but since the progress report for Apple DWARF indices has been removed this commit removes that decorator.
2024-01-16[lldb] Hoist SupportFile out of FileSpecList (NFC)Jonas Devlieghere2-28/+53
This hoists SupportFile out of FileSpecList. SupportFileList is still implemented there as it's very similar to FileSpecList.
2024-01-16Recommit "[AST] Use APIntStorage to fix memory leak in EnumConstantDecl. ↵Craig Topper1-1/+1
(#78311)" With lldb build fix. Original message: EnumConstantDecl is allocated by the ASTContext allocator so the destructor is never called. This patch takes a similar approach to IntegerLiteral by using APIntStorage to allocate large APSInts using the ASTContext allocator as well. The downside is that an additional heap allocation and copy of the data needs to be made when calling getInitValue if the APSInt is large. Fixes #78160.
2024-01-16Work around a bug in the interaction between newer dyld's and older ↵jimingham1-0/+8
simulator dyld's (#78004) There's a bad interaction between the macOS 14 dyld and the "dyld_sim" shim that comes from older (iOS 15) simulator downloads that results in dyld reporting some modules twice in the return from the dyld callback to list modules. The records were identical, but lldb wasn't happy with seeing the duplicates... Since it's not possible to load two different modules at the same address, this change just picks the first instance of any entries that have the same load address. There really isn't a good way to test this patch.
2024-01-16[lldb][Progress] Separate title and details (#77547)Chelsea Cassanova9-33/+45
Per this RFC: https://discourse.llvm.org/t/rfc-improve-lldb-progress-reporting/75717 on improving progress reports, this commit separates the title field and details field so that the title specifies the category that the progress report falls under. The details field is added as a part of the constructor for progress reports and by default is an empty string. In addition, changes the total amount of progress completed into a std::optional. Also updates the test to check for details being correctly reported from the event structured data dictionary.
2024-01-16[lldb] Add LLDB_BUG_REPORT_URL macro to allow a different URL for lldb bug ↵Zequan Wu4-2/+11
reporting. (#78210) This allows release teams to customize the bug report url for lldb. It also removes unnecessary constructions of `llvm::PrettyStackTraceProgram` as it's already constructed inside `llvm::InitLLVM`.