Reland "[lldb] Add support for using integral const static data members in the expression evaluator"

Reland 486787210d which broke tests on Arm and Windows.

* Windows -- on Windows const static dat

Reland "[lldb] Add support for using integral const static data members in the expression evaluator"

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.

show more ...

Revert "[lldb] Add support for using integral const static data members in the expression evaluator"

This reverts commit 486787210df5ce5eabadc90a7de353ae81101feb.

This broke the windows lldb bot: h

Revert "[lldb] Add support for using integral const static data members in the expression evaluator"

This reverts commit 486787210df5ce5eabadc90a7de353ae81101feb.

This broke the windows lldb bot: https://lab.llvm.org/buildbot/#/builders/83/builds/21186

show more ...

[lldb] Add support for using integral const static data members in the expression evaluator

This adds support for using const static integral data members as described by C++11 [class.static.data]p3

[lldb] Add support for using integral const static data members in the expression evaluator

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

show more ...

Reland "[LLDB][NFC] Decouple dwarf location table from DWARFExpression."

This reland 227dffd0b6d78154516ace45f6ed28259c7baa48 and
562c3467a6738aa89203f72fc1d1343e5baadf3c with failed api tests fixed

Reland "[LLDB][NFC] Decouple dwarf location table from DWARFExpression."

This reland 227dffd0b6d78154516ace45f6ed28259c7baa48 and
562c3467a6738aa89203f72fc1d1343e5baadf3c with failed api tests fixed by keeping
function base file addres in DWARFExpressionList.

show more ...

Revert "[LLDB][NFC] Decouple dwarf location table from DWARFExpression."

This reverts commit 227dffd0b6d78154516ace45f6ed28259c7baa48 and its
follow up 562c3467a6738aa89203f72fc1d1343e5baadf3c becau

Revert "[LLDB][NFC] Decouple dwarf location table from DWARFExpression."

This reverts commit 227dffd0b6d78154516ace45f6ed28259c7baa48 and its
follow up 562c3467a6738aa89203f72fc1d1343e5baadf3c because it breaks a
bunch of tests on GreenDragon:

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45155/

show more ...

[LLDB][NFC] Decouple dwarf location table from DWARFExpression.

Differential Revision: https://reviews.llvm.org/D125509

[lldb] Use value_or instead of getValueOr (NFC)

[lldb][NFC] Move non-clang specific method to the generic DWARF Parser

This patch renames DW_ACCESS_to_AccessType function and move it to the abstract
DWARFASTParser, since there is no clang-specifi

[lldb][NFC] Move non-clang specific method to the generic DWARF Parser

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

show more ...

[lldb][NFC] Move generic DWARFASTParser code out of Clang-specific code

This patch moves ParseChildArrayInfo out of DWARFASTParserClang in order
to decouple Clang-specific logic from DWARFASTParser.

[lldb][NFC] Move generic DWARFASTParser code out of Clang-specific code

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 <[email protected]>

show more ...

Filter non-external static members from SBType::GetFieldAtIndex.

See [[ https://github.com/llvm/llvm-project/issues/55040 | issue 55040 ]] where static members of classes declared in the anonymous n

Filter non-external static members from SBType::GetFieldAtIndex.

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

show more ...

[lldb/DWARF] Fix linking direction in CopyUniqueClassMethodTypes

IIUC, the purpose of CopyUniqueClassMethodTypes is to link together
class definitions in two compile units so that we only have a sin

[lldb/DWARF] Fix linking direction in CopyUniqueClassMethodTypes

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

show more ...

[lldb/DWARF] Fix a typo in 57f99d0dc3

The lambda should take a reference argument.

[lldb] Reduce duplication in DWARFASTParserClang::CopyUniqueClassMethodTypes

Use lambdas to replace identical bits of code.

[LLDB] Remove cases of using namespace llvm:: from header file

We have using namespace llvm::dwarf in dwarf.h header globally. Replacing that
with a using namespace within lldb_private::dwarf and mo

[LLDB] Remove cases of using namespace llvm:: from header file

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

show more ...

[lldb] Convert DWARF log to the new API

This also deletes some dead log statements (log initialization commented
out).

[lldb] Use nullptr instead of 0 or NULL (NFC)

This is a re-submission of 24d240558811604354a8d6080405f6bad8d15b5c
without the hunks in HostNativeThreadBase.{h,cpp}, which break builds
on Windows.

I

[lldb] Use nullptr instead of 0 or NULL (NFC)

This is a re-submission of 24d240558811604354a8d6080405f6bad8d15b5c
without the hunks in HostNativeThreadBase.{h,cpp}, which break builds
on Windows.

Identified with modernize-use-nullptr.

show more ...

Revert "[lldb] Use nullptr instead of 0 or NULL (NFC)"

This reverts commit 913457acf07be7f22d71ac41ad1076517d7f45c6.

It again broke builds on Windows:

lldb/source/Host/common/HostNativeThreadBas

Revert "[lldb] Use nullptr instead of 0 or NULL (NFC)"

This reverts commit 913457acf07be7f22d71ac41ad1076517d7f45c6.

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'

show more ...

[lldb] Use nullptr instead of 0 or NULL (NFC)

This is a re-submission of 24d240558811604354a8d6080405f6bad8d15b5c
without the hunk in HostNativeThreadBase.h, which breaks builds on
Windows.

Identif

[lldb] Use nullptr instead of 0 or NULL (NFC)

This is a re-submission of 24d240558811604354a8d6080405f6bad8d15b5c
without the hunk in HostNativeThreadBase.h, which breaks builds on
Windows.

Identified with modernize-use-nullptr.

show more ...

Revert "[lldb] Use nullptr instead of 0 or NULL (NFC)"

This reverts commit 24d240558811604354a8d6080405f6bad8d15b5c.
Breaks building on Windows:

../../lldb/include\lldb/Host/HostNativeThreadBas

Revert "[lldb] Use nullptr instead of 0 or NULL (NFC)"

This reverts commit 24d240558811604354a8d6080405f6bad8d15b5c.
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.

show more ...

[lldb] Use nullptr instead of 0 or NULL (NFC)

Identified with modernize-use-nullptr.

[LLDB][DWARF] Fix duplicate TypeSP in type list

Differential Revision: https://reviews.llvm.org/D115308

[lldb][NFC] StringRef-ify the name parameter in CreateEnumerationType

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D113176

[lldb] Update field offset/sizes when encountering artificial members such as vtable pointers

`DWARFASTParserClang::ParseSingleMember` turns DWARF DIEs that describe
struct/class members into their

[lldb] Update field offset/sizes when encountering artificial members such as vtable pointers

`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

show more ...

[lldb][NFC] Move a declaration in DWARFASTParserClang to its first use.

[lldb][NFC] Use llvm::Optional to refer to Optional

clang::Optional is just an alias used within Clang.