Reland 486787210d which broke tests on Arm and Windows.
* Windows -- on Windows const static data members with no out-of-class
definition do have valid addresses, in constract to other platforms
(Linux, macos) where they don't. Adjusted the test to expect success
on Windows and failure on other platforms.
* Arm -- `int128` is not available on 32-bit ARM, so disable the test
for this architecture.
This adds support for using const static integral data members as described by C++11 [class.static.data]p3
to LLDB's expression evaluator.
So far LLDB treated these data members are normal static variables. They already work as intended when they are declared in the class definition and then defined in a namespace scope. However, if they are declared and initialised in the class definition but never defined in a namespace scope, all LLDB expressions that use them will fail to link when LLDB can't find the respective symbol for the variable.
The reason for this is that the data members which are only declared in the class are not emitted into any object file so LLDB can never resolve them. Expressions that use these variables are expected to directly use their constant value if possible. Clang can do this for us during codegen, but it requires that we add the constant value to the VarDecl we generate for these data members.
This patch implements this by:
* parsing the constant values from the debug info and adding it to variable declarations we encounter.
* ensuring that LLDB doesn't implicitly try to take the address of expressions that might be an lvalue that points to such a special data member.
The second change is caused by LLDB's way of storing lvalues in the expression parser. When LLDB parses an expression, it tries to keep the result around via two mechanisms:
1. For lvalues, LLDB generates a static pointer variable and stores the address of the last expression in it: `T *$__lldb_expr_result_ptr = &LastExpression`
2. For everything else, LLDB generates a static variable of the same type as the last expression and then direct initialises that variable: `T $__lldb_expr_result(LastExpression)`
If we try to print a special const static data member via something like `expr Class::Member`, then LLDB will try to take the address of this expression as it's an lvalue. This means LLDB will try to take the address of the variable which causes that Clang can't replace the use with the constant value. There isn't any good way to detect this case (as there a lot of different expressions that could yield an lvalue that points to such a data member), so this patch also changes that we only use the first way of capturing the result if the last expression does not have a type that could potentially indicate it's coming from such a special data member.
This change shouldn't break most workflows for users. The only observable side effect I could find is that the implicit persistent result variables for const int's now have their own memory address:
Before this change:
```
(lldb) p i
(const int) $0 = 123
(lldb) p &$0
(const int *) $1 = 0x00007ffeefbff8e8
(lldb) p &i
(const int *) $2 = 0x00007ffeefbff8e8
```
After this change we capture `i` by value so it has its own value.
```
(lldb) p i
(const int) $0 = 123
(lldb) p &$0
(const int *) $1 = 0x0000000100155320
(lldb) p &i
(const int *) $2 = 0x00007ffeefbff8e8
```
Reviewed By: Michael137
Differential Revision: https://reviews.llvm.org/D81471
This patch renames DW_ACCESS_to_AccessType function and move it to the abstract
DWARFASTParser, since there is no clang-specific code there. This is useful for
plugins other than Clang.
Reviewed By: shafik, bulbazord
Differential Revision: https://reviews.llvm.org/D114719
This patch moves ParseChildArrayInfo out of DWARFASTParserClang in order
to decouple Clang-specific logic from DWARFASTParser.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D114668
Signed-off-by: Luís Ferreira <contact@lsferreira.net>
See [[ https://github.com/llvm/llvm-project/issues/55040 | issue 55040 ]] where static members of classes declared in the anonymous namespace are incorrectly returned as member fields from lldb::SBType::GetFieldAtIndex(). It appears that attrs.member_byte_offset contains a sentinel value for members that don't have a DW_AT_data_member_location.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D124409
IIUC, the purpose of CopyUniqueClassMethodTypes is to link together
class definitions in two compile units so that we only have a single
definition of a class. It does this by adding entries to the die_to_type
and die_to_decl_ctx maps.
However, the direction of the linking seems to be reversed. It is taking
entries from the class that has not yet been parsed, and copying them to
the class which has been parsed already -- i.e., it is a very
complicated no-op.
Changing the linking order allows us to revert the changes in D13224
(while keeping the associated test case passing), and is sufficient to
fix PR54761, which was caused by an undesired interaction with that
patch.
Differential Revision: https://reviews.llvm.org/D124370
We have using namespace llvm::dwarf in dwarf.h header globally. Replacing that
with a using namespace within lldb_private::dwarf and moving to a
using namespace lldb_private::dwarf in .cpp files and fully qualified names
in the few header files.
Differential Revision: https://reviews.llvm.org/D120836
This is a re-submission of 24d2405588
without the hunks in HostNativeThreadBase.{h,cpp}, which break builds
on Windows.
Identified with modernize-use-nullptr.
This reverts commit 913457acf0.
It again broke builds on Windows:
lldb/source/Host/common/HostNativeThreadBase.cpp(37,14): error:
assigning to 'lldb::thread_result_t' (aka 'unsigned int') from
incompatible type 'std::nullptr_t'
This is a re-submission of 24d2405588
without the hunk in HostNativeThreadBase.h, which breaks builds on
Windows.
Identified with modernize-use-nullptr.
This reverts commit 24d2405588.
Breaks building on Windows:
../../lldb/include\lldb/Host/HostNativeThreadBase.h(49,36): error:
cannot initialize a member subobject of type 'lldb::thread_result_t'
(aka 'unsigned int') with an rvalue of type 'std::nullptr_t'
lldb::thread_result_t m_result = nullptr;
^~~~~~~
1 error generated.
`DWARFASTParserClang::ParseSingleMember` turns DWARF DIEs that describe
struct/class members into their respective Clang representation (e.g.,
clang::FieldDecl). It also updates a record of where the last field
started/ended so that we can speculatively fill any holes between a field and a
bitfield with unnamed bitfield padding.
Right now we are completely ignoring 'artificial' members when parsing the DWARF
of a struct/class. The only artificial member that seems to be emitted in
practice for C/C++ seems to be the vtable pointer.
By completely skipping both the Clang AST node creation and the updating of the
last-field record, we essentially leave a hole in our layout with the size of
our artificial member. If the next member is a bitfield we then speculatively
fill the hole with an unnamed bitfield. During CodeGen Clang inserts an
artificial vtable pointer into the layout again which now occupies the same
offset as the unnamed bitfield. This later brings down Clang's
`CGRecordLowering::insertPadding` when it checks that none of the fields of the
generated record layout overlap.
Note that this is not a Clang bug. We explicitly set the offset of our fields in
LLDB and overwrite whatever Clang makes up.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D112697
Front-load the first_valid_code_address check, so that we avoid creating
the function object (instead of simply refusing to use it in queries).
Differential Revision: https://reviews.llvm.org/D112310
Right now DWARFASTParserClang::ParseSingleMember has two parts: One part parses
Objective-C properties and the other part parses C/C++ members/Objective-C
ivars. These parts are pretty much independent of each other (with one
historical exception, see below) and in practice they parse DIEs with different
tags/attributes: `DW_TAG_APPLE_property` and `DW_TAG_member`.
I don't see a good reason for keeping the different parsing code intertwined in
a single function, so instead split out the Objective-C property parser into its
own function.
Note that 90% of this commit is just unindenting nearly all of
`ParseSingleMember` which was inside a `if (tag == DW_TAG_member)` block. I.e.,
think of the old `ParseSingleMember` function as: The rest is just moving the
property parsing code into its own function and I added the ReportError
implementation in case we fail to resolve the property type (which before was
just a silent failure).
```
lang=c++
void DWARFASTParserClang::ParseSingleMember(...) {
[...]
if (tag == DW_TAG_member) {
[...] // This huge block got unindented in this patch as the `if` above is gone.
}
if (property) {
[...] // This is the property parsing code that is now its own function.
}
}
```
There is one exception to the rule that the parsers are independent. Before 2012
Objective-C properties were encoded as `DW_TAG_member` with
`DW_AT_APPLE_property*` attributes describing the property. In 2012 this has
changed in a series of commits (see for example
c0449635b3 which updates the docs) so that
`DW_TAG_APPLE_property` is now used for properties. With the old format we first
created an ivar and afterwards used the `DW_AT_APPLE_property*` attributes to
create the respective property, but there doesn't seem to be any way to create
such debug info with any clang from the last 9 years. So this is technically not
NFC in case some finds debug info from that time and tries to use properties.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D111632
Just moving that block inside DWARFASTParserClang::ParseChildMembers into
its own function. Also early-exiting instead of a large if when
num_attributes is 0.
D68422 introduced `ParsedDWARFTypeAttributes` which encapsulated attribute
parsing and storage into its own small struct. This patch is doing the same for
the member type attribute parsing. One utility class is parsing normal member
attributes and the other is parsing the dedicated Objective-C property
attributes.
Right now the patch just makes the `ParseSingleMember` function a bit shorter,
but the bigger benefit is that we can now split up the function into Objective-C
property parsing and parsing of normal members (struct/class members and
Objective-C ivars). The only shared code between those two parsing logic is the
normal member attribute parsing.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D111494
This adds support for parsing DW_AT_calling_convention in the DWARF parser.
The generic DWARF parsing code already support extracting this attribute from A
DIE and TypeSystemClang already offers a parameter to add a calling convention
to a function type (as the PDB parser supports calling convention parsing), so
this patch just converts the DWARF enum value to the Clang enum value and adds a
few tests.
There are two tests in this patch.:
* A unit test for the added DWARF parsing code that should run on all platforms.
* An API tests that covers the whole expression evaluation machinery by trying
to call functions with non-standard calling conventions. The specific subtests
are target specific as some calling conventions only work on e.g. win32 (or, if
they work on other platforms they only really have observable differences on a
specific target). The tests are also highly compiler-specific, so if GCC or
Clang tell us that they don't support a specific calling convention then we just
skip the test.
Note that some calling conventions are supported by Clang but aren't implemented
in LLVM (e.g. `pascal`), so there we just test that if this ever gets
implemented in LLVM that LLDB works too. There are also some more tricky/obscure
conventions that are left out such as the different swift* conventions, some
planned Obj-C conventions (`Preserve*`), AAPCS* conventions (as the DWARF->Clang
conversion is ambiguous for AAPCS and APPCS-VFP) and conventions only used for
OpenCL etc.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D108629
ParseSingleMember has two large ifs around the back of it's body:
`if (!is_artificial)` and `if (member_type)`. This patch just converts those
to early-exits. The patch is NFC. It even retains the curious fact that
Objective-C properties that fail to parse are silently ignored, but now there
is at least a FIXME that points this out.
As pointed out in D107434 by Walter, D103172 also changed two for loops that
were actually not just iterating over some DIEs but also using the iteration
variable later on for some other things. This patch reverts the respective
faulty parts of D103172.
This patch adds the ability to get a DWARFDIE's children as an LLVM range.
This way we can use for range loops to iterate over them and we can use LLVM's
algorithms like `llvm::all_of` to query all children.
The implementation has to do some small shenanigans as the iterator needs to
store a DWARFDIE, but a DWARFDIE container is also a DWARFDIE so it can't return
the iterator by value. I just made the `children` getter a templated function to
avoid the cyclic dependency.
Reviewed By: #lldb, werat, JDevlieghere
Differential Revision: https://reviews.llvm.org/D103172
LLDB's DWARF parser has some heuristics for guessing and fixing up the
accessibility of C++ class/struct members after they were already created in the
internal Clang AST. The heuristic is that if a struct/class has a base class,
then it's actually a class and it's members are private unless otherwise
specified.
From what I can see this heuristic isn't sound and also unnecessary. The idea
that inheritance implies that the `class` keyword was used and the default
visibility is `private` is incorrect. Also both GCC and Clang use
`DW_TAG_structure_type` and `DW_TAG_class_type` for `struct` and `class` types
respectively, so the default visibility we infer from that information is always
correct and there is no need to fix it up.
And finally, the access specifiers we set in the Clang AST are anyway unused
within LLDB. The expression parser explicitly ignores them to give users access
to private members and there is not SBAPI functionality that exposes this
information.
This patch removes all the heuristic code for the reasons above and instead
just relies on the access values we infer from the tag kind and explicit
annotations in DWARF.
This patch is NFCI.
Reviewed By: werat
Differential Revision: https://reviews.llvm.org/D105463
C doesn't allow empty structs but Clang/GCC support them and give them a size of 0.
LLDB implements this by checking the tag kind and if it's `DW_TAG_structure_type` then
we give it a size of 0 via an empty external RecordLayout. This is done because our
internal TypeSystem is always in C++ mode (which means we would give them a size
of 1).
The current check for when we have this special case is currently too lax as types with
`DW_TAG_structure_type` can also occur in C++ with types defined using the `struct`
keyword. This means that in a C++ program with `struct Empty{};`, LLDB would return
`0` for `sizeof(Empty)` even though the correct size is 1.
This patch removes this special case and replaces it with a generic approach that just
assigns empty structs the byte_size as specified in DWARF. The GCC/Clang special
case is handles as they both emit an explicit `DW_AT_byte_size` of 0. And if another
compiler decides to use a different byte size for this case then this should also be
handled by the same code as long as that information is provided via `DW_AT_byte_size`.
Reviewed By: werat, shafik
Differential Revision: https://reviews.llvm.org/D105471
when dealing with -gmodules debug info.
This fixes the bot failures on Darwin.
A recent clang change (presumably https://reviews.llvm.org/D104291)
introduced a bug where .pcm files would identify themselves as
DW_LANG_C_plus_plus, but the .o that references them would identify as
DW_LANG_C_plus_plus_14. While that bug needs to be fixed, too, it
shows that the current strict comparison also isn't meaningful.
rdar://79423225
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
We have a bug in which using member_clang_type.GetByteSize() triggers record
layout and during this process since the record was not yet complete we ended
up reaching a record that had not been layed out yet.
Using member_type->GetByteSize() avoids this situation since it relies on size
from DWARF and will not trigger record layout.
For reference: rdar://77293040
Differential Revision: https://reviews.llvm.org/D102445
When LLDB's DWARF parser is parsing the member DIEs of a struct/class it
currently fully resolves the types of static member variables in a class before
adding the respective `VarDecl` to the record.
For record types fully resolving the type will also parse the member DIEs of the
respective class. The other way of resolving is just 'forward' resolving the type
which will try to load only the minimum amount of information about the type
(for records that would only be the name/kind of the type). Usually we always
resolve types on-demand so it's rarely useful to speculatively fully resolve
them on the first use.
This patch changes makes that we only 'forward' resolve the types of static
members. This solves the fact that LLDB unnecessarily loads debug information
to parse the type if it's maybe not needed later and it also avoids a crash where
the parsed type might in turn reference the surrounding class that is currently
being parsed.
The new test case demonstrates the crash that might happen. The crash happens
with the following steps:
1. We parse class `ToLayout` and it's members.
2. We parse the static class member and fully resolve its type
(`DependsOnParam2<ToLayout>`).
3. That type has a non-static class member `DependsOnParam1<ToLayout>` for which
LLDB will try to calculate the size.
4. The layout (and size)`DependsOnParam1<ToLayout>` turns depends on the
`ToLayout` size/layout.
5. Clang will calculate the record layout/size for `ToLayout` even though we are
currently parsing it and it's missing it's non-static member.
The created is missing the offset for the yet unparsed non-static member. If we
later try to get the offset we end up hitting different asserts. Most common is
the one in `TypeSystemClang::DumpValue` where it checks that the record layout
has offsets for the current FieldDecl.
```
assert(field_idx < record_layout.getFieldCount());
```
Fixed rdar://67910011
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D100180
Apply changes from https://reviews.llvm.org/D91014 to other places where DWARF entries are being processed.
Test case is provided by @jankratochvil.
The test is marked to run only on x64 and exclude Windows and Darwin, because the assembly is not OS-independent.
(First attempt https://reviews.llvm.org/D96778 broke the build bots)
Reviewed By: jankratochvil
Differential Revision: https://reviews.llvm.org/D97765
