summaryrefslogtreecommitdiff
path: root/lldb/test/API/functionalities/limit-debug-info/TestLimitDebugInfo.py
AgeCommit message (Collapse)Author
2024-02-16[lldb] Replace assertEquals with assertEqual (NFC) (#82073)Jonas Devlieghere
assertEquals is a deprecated alias for assertEqual and has been removed in Python 3.12. This wasn't an issue previously because we used a vendored version of the unittest module. Now that we use the built-in version this gets updated together with the Python version used to run the test suite.
2023-05-25[NFC][Py Reformat] Reformat python files in lldbJonas Devlieghere
This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with `black` (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run `git checkout --ours <yourfile>` and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460
2022-11-30Report which modules have forcefully completed types in statistics.Greg Clayton
A previous patch added the ability for us to tell if types were forcefully completed. This patch adds the ability to see which modules have forcefully completed types and aggregates the number of modules with forcefully completed types at the root level. We add a module specific setting named "debugInfoHadIncompleteTypes" that is a boolean value. We also aggregate the number of modules at the root level that had incomplete debug info with a key named "totalModuleCountWithIncompleteTypes" that is a count of number of modules that had incomplete types. Differential Revision: https://reviews.llvm.org/D138638
2022-11-23Add the ability to see when a type in incomplete.Greg Clayton
-flimit-debug-info and other compiler options might end up removing debug info that is needed for debugging. LLDB marks these types as being forcefully completed in the metadata in the TypeSystem. These types should have been complete in the debug info but were not because the compiler omitted them to save space. When we can't find a suitable replacement for the type, we should let the user know that these types are incomplete to indicate there was an issue instead of just showing nothing for a type. The solution is to display presented in this patch is to display "<incomplete type>" as the summary for any incomplete types. If there is a summary string or function that is provided for a type, but the type is currently forcefully completed, the installed summary will be ignored and we will display "<incomplete type>". This patch also exposes the ability to ask a SBType if it was forcefully completed with: bool SBType::IsTypeForcefullyCompleted(); This will allow the user interface for a debugger to also detect this issue and possibly mark the variable display up on some way to indicate to the user the type is incomplete. To show how this is diplayed, we can look at the existing output first for the example source file from the file: lldb/test/API/functionalities/limit-debug-info/main.cpp (lldb) frame variable inherits_from_one inherits_from_two one_as_member two_as_member array_of_one array_of_two shadowed_one (InheritsFromOne) ::inherits_from_one = (member = 47) (InheritsFromTwo) ::inherits_from_two = (member = 47) (OneAsMember) ::one_as_member = (one = member::One @ 0x0000000100008028, member = 47) (TwoAsMember) ::two_as_member = (two = member::Two @ 0x0000000100008040, member = 47) (array::One [3]) ::array_of_one = ([0] = array::One @ 0x0000000100008068, [1] = array::One @ 0x0000000100008069, [2] = array::One @ 0x000000010000806a) (array::Two [3]) ::array_of_two = ([0] = array::Two @ 0x0000000100008098, [1] = array::Two @ 0x0000000100008099, [2] = array::Two @ 0x000000010000809a) (ShadowedOne) ::shadowed_one = (member = 47) (lldb) frame variable --show-types inherits_from_one inherits_from_two one_as_member two_as_member array_of_one array_of_two shadowed_one (InheritsFromOne) ::inherits_from_one = { (int) member = 47 } (InheritsFromTwo) ::inherits_from_two = { (int) member = 47 } (OneAsMember) ::one_as_member = { (member::One) one = {} (int) member = 47 } (TwoAsMember) ::two_as_member = { (member::Two) two = {} (int) member = 47 } (array::One [3]) ::array_of_one = { (array::One) [0] = {} (array::One) [1] = {} (array::One) [2] = {} } (array::Two [3]) ::array_of_two = { (array::Two) [0] = {} (array::Two) [1] = {} (array::Two) [2] = {} } (ShadowedOne) ::shadowed_one = { (int) member = 47 } With this patch in place we can now see any classes that were forcefully completed to let us know that we are missing information: (lldb) frame variable inherits_from_one inherits_from_two one_as_member two_as_member array_of_one array_of_two shadowed_one (InheritsFromOne) ::inherits_from_one = (One = <incomplete type>, member = 47) (InheritsFromTwo) ::inherits_from_two = (Two = <incomplete type>, member = 47) (OneAsMember) ::one_as_member = (one = <incomplete type>, member = 47) (TwoAsMember) ::two_as_member = (two = <incomplete type>, member = 47) (array::One[3]) ::array_of_one = ([0] = <incomplete type>, [1] = <incomplete type>, [2] = <incomplete type>) (array::Two[3]) ::array_of_two = ([0] = <incomplete type>, [1] = <incomplete type>, [2] = <incomplete type>) (ShadowedOne) ::shadowed_one = (func_shadow::One = <incomplete type>, member = 47) (lldb) frame variable --show-types inherits_from_one inherits_from_two one_as_member two_as_member array_of_one array_of_two shadowed_one (InheritsFromOne) ::inherits_from_one = { (One) One = <incomplete type> {} (int) member = 47 } (InheritsFromTwo) ::inherits_from_two = { (Two) Two = <incomplete type> {} (int) member = 47 } (OneAsMember) ::one_as_member = { (member::One) one = <incomplete type> {} (int) member = 47 } (TwoAsMember) ::two_as_member = { (member::Two) two = <incomplete type> {} (int) member = 47 } (array::One[3]) ::array_of_one = { (array::One) [0] = <incomplete type> {} (array::One) [1] = <incomplete type> {} (array::One) [2] = <incomplete type> {} } (array::Two[3]) ::array_of_two = { (array::Two) [0] = <incomplete type> {} (array::Two) [1] = <incomplete type> {} (array::Two) [2] = <incomplete type> {} } (ShadowedOne) ::shadowed_one = { (func_shadow::One) func_shadow::One = <incomplete type> {} (int) member = 47 } Differential Revision: https://reviews.llvm.org/D138259
2022-06-17[lldb][tests] Automatically call compute_mydir (NFC)Dave Lee
Eliminate boilerplate of having each test manually assign to `mydir` by calling `compute_mydir` in lldbtest.py. Differential Revision: https://reviews.llvm.org/D128077
2021-06-21[lldb] Skip TestLimitDebugInfo for Clang<7Raphael Isemann
Without DW_CC_pass_by_* attributes that Clang 7 started to emit in this test we don't properly read back the return value of the `get_*` functions and just read bogus memory. See also the TestReturnValue.py test.
2020-08-14[lldb] Check Decl kind when completing -flimit-debug-info typesPavel Labath
The search for the complete class definition can also produce entries which are not of the expected type. This can happen for instance when there is a function with the same name as the class we're looking up (which means that the class needs to be disambiguated with the struct/class tag in most contexts). Previously we were just picking the first Decl that the lookup returned, which later caused crashes or assertion failures if it was not of the correct type. This patch changes that to search for an entry of the correct type. Differential Revision: https://reviews.llvm.org/D85904
2020-07-27[lldb/DWARF] Don't treat class declarations with children as definitionsPavel Labath
Summary: This effectively reverts r188124, which added code to handle (DW_AT_)declarations of structures with some kinds of children as definitions. The commit message claims this is a workaround for some kind of debug info produced by gcc. However, it does not go into specifics, so it's hard to reproduce or verify that this is indeed still a problem. Having this code is definitely a problem though, because it mistakenly declares incomplete dwarf declarations to be complete. Both clang (with -flimit-debug-info) and gcc (by default) generate DW_AT_declarations of structs with children. This happens when full debug info for a class is not emitted in a given compile unit (e.g. because of vtable homing), but the class has inline methods which are used in the given compile unit. In that case, the compilers emit a DW_AT_declaration of a class, but add a DW_TAG_subprogram child to it to describe the inlined instance of the method. Even though the class tag has some children, it definitely does not contain enough information to construct a full class definition (most notably, it lacks any members). Keeping the class as incomplete allows us to search for a real definition in other modules, helping the -flimit-debug-info flow. And in case the definition is not found we can display a error message saying that, instead of just showing an empty struct. Reviewers: clayborg, aprantl, JDevlieghere, shafik Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D83302
2020-07-06[lldb/DWARF] Look for complete array element definitions in other modulesPavel Labath
This applies the same logic we have for incomplete class bases and members to array element types.
2020-07-03[lldb/DWARF] Look for complete member definitions in other modulesPavel Labath
With -flimit-debug-info, we can have a definition of a class, but no definition for some of its members. This extends the same logic we were using for incomplete base classes to cover incomplete members too. Test forward-declarations.s is removed as it is no longer applicable -- we don't warn anymore when encountering incomplete members as they could be completed elsewhere. New checks added to TestLimitDebugInfo cover the handling of incomplete members more thoroughly.
2020-07-02[lldb] Skip TestLimitDebugInfo on windowsPavel Labath
The test does not work on windows, because clang will emit full type information for __declspec(dllexport) types even under -flimit-debug-info. __declspec(dllexport) is needed to be able to use the type across shared library boundaries on windows, which makes this a pretty good heuristic, but defeats the purpose of this test. I am going to create (in another patch) an basic assembly test, so that the relevant code gets at least some coverage on windows hosts. This also reverts commit 1276855f2b4485ec312b379c1b8eaf5510d9b157, which added the __declspec annotations -- they are not necessary anymore, and they needlessly complicate the test.
2020-07-01[lldb] Add basic -flimit-debug-info support to expression evaluatorPavel Labath
Summary: This patch adds support for evaluation of expressions referring to types which were compiled in -flimit-debug-info (a.k.a -fno-standalone-debug) in clang. In this mode it's possible that the debug information needed to fully describe a c++ type is not present in a single shared library -- for example debug info for a base class or a member of a type can only be found in another shared library. This situation is not currently handled well within lldb as we are limited to searching within a single shared library (lldb_private::Module) when searching for the definition of these types. The way that this patch gets around this limitation is by doing the search at a later stage -- during the construction of the expression ast context. This works by having the parser (currently SymbolFileDWARF, but a similar approach is probably needed for PDBs too) mark a type as "forcefully completed". What this means is that the parser has marked the type as "complete" in the module ast context (as this is necessary to e.g. derive classes from it), but its definition is not really there. This is done via a new field on the ClangASTMetadata struct. Later, when we are importing such a type into the expression ast, we check this flag. If the flag is set, we try to find a better definition for the type in other shared libraries. We do this by initiating a new lookup for the "forcefully completed" classes, which then imports the type from a module with a full definition. This patch only implements this handling for base classes, but other cases (members, array element types, etc.). The changes for that should be fairly simple and mostly revolve around marking these types as "forcefully completed" at an approriate time -- the importing logic is generic already. Another aspect, which is also not handled by this patch is viewing these types via the "frame variable" command. This does not use the AST importer and so it will need to handle these types on its own -- that will be the subject of another patch. Differential Revision: https://reviews.llvm.org/D81561