13 Commits

Author SHA1 Message Date
Jonas Devlieghere
80fcecb13c
[lldb] Replace assertEquals with assertEqual (NFC) (#82073)
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.
2024-02-16 20:58:50 -08:00
Jonas Devlieghere
2238dcc393
[NFC][Py Reformat] Reformat python files in lldb
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
2023-05-25 12:54:09 -07:00
Greg Clayton
fc743f034a Report which modules have forcefully completed types in statistics.
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-30 21:22:27 -08:00
Greg Clayton
d941fceca8 Add the ability to see when a type in incomplete.
-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-11-23 10:07:12 -08:00
Dave Lee
4cc8f2a017 [lldb][tests] Automatically call compute_mydir (NFC)
Eliminate boilerplate of having each test manually assign to `mydir` by calling
`compute_mydir` in lldbtest.py.

Differential Revision: https://reviews.llvm.org/D128077
2022-06-17 14:34:49 -07:00
Raphael Isemann
1265f05c26 [lldb] Skip TestLimitDebugInfo for Clang<7
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.
2021-06-21 19:46:29 +02:00
Pavel Labath
fdc6aea3fd [lldb] Check Decl kind when completing -flimit-debug-info types
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-08-14 12:31:37 +02:00
Pavel Labath
1956cf1042 [lldb/DWARF] Don't treat class declarations with children as definitions
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-27 12:58:22 +02:00
Pavel Labath
b65d4b23f6 [lldb/DWARF] Look for complete array element definitions in other modules
This applies the same logic we have for incomplete class bases and
members to array element types.
2020-07-06 10:09:13 +02:00
Pavel Labath
b3b952873f [lldb/DWARF] Look for complete member definitions in other modules
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-03 16:50:49 +02:00
Pavel Labath
d6343e607a [lldb] Skip TestLimitDebugInfo on windows
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-02 14:34:33 +02:00
Pavel Labath
1276855f2b [lldb] Attempt to fix TestLimitDebugInfo on windows
The test fails due to link errors. I believe this change should fix
that.
2020-07-01 16:56:56 +02:00
Pavel Labath
a03dc8c9fa [lldb] Add basic -flimit-debug-info support to expression evaluator
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
2020-07-01 14:50:14 +02:00