| Age | Commit message (Collapse) | Author |
|---|
|
compiler versions
The existing XFAIL was being ignored because of the `expectedFailureDarwin`
causing failures on the matrix macOS bot:
```
======================================================================
FAIL: test_inline_static_members_dwarf5_dsym (TestConstStaticIntegralMember.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1769, in test_method
return attrvalue(self)
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 151, in test_inline_static_members_dwarf5
self.check_inline_static_members("-gdwarf-5")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 129, in check_inline_static_members
self.check_global_var("A::int_val", "const int", "1")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 118, in check_global_var
self.assertGreaterEqual(len(var_list), 1)
AssertionError: 0 not greater than or equal to 1
Config=x86_64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/bin/clang
======================================================================
FAIL: test_shadowed_static_inline_members_dwarf5_dsym (TestConstStaticIntegralMember.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1769, in test_method
return attrvalue(self)
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 205, in test_shadowed_static_inline_members_dwarf5
self.check_shadowed_static_inline_members("-gdwarf-5")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 192, in check_shadowed_static_inline_members
self.check_global_var("ns::Foo::mem", "const int", "10")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 118, in check_global_var
self.assertGreaterEqual(len(var_list), 1)
AssertionError: 0 not greater than or equal to 1
Config=x86_64-/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/bin/clang
----------------------------------------------------------------------
```
|
|
The `compiler` parameter is not supported in the `expectedFailureDarwin`
decorator.
Change the decorator to `expectedFailureAll`, which is fine because
this only affects the `dsym` variant (which is only a macOS variant).
|
|
compiler verions
Follow-up to https://github.com/llvm/llvm-project/pull/111859. Prior
to this PR we would never run these tests with DWARFv5 on older Clang
versions (since default wasn't DWARFv5 on macOS until recently). The
patch explicitly started running some of these tests with DWARFv5.
These were failing on the macOS matrix bot (with Clang-15/Clang-17).
```
======================================================================
FAIL: test_inline_static_members_dwarf5_dsym (TestConstStaticIntegralMember.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1769, in test_method
return attrvalue(self)
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 150, in test_inline_static_members_dwarf5
self.check_inline_static_members("-gdwarf-5")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 129, in check_inline_static_members
self.check_global_var("A::int_val", "const int", "1")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 118, in check_global_var
self.assertGreaterEqual(len(var_list), 1)
AssertionError: 0 not greater than or equal to 1
```
|
|
Darwin (#115401)
https://github.com/llvm/llvm-project/pull/111859 fixed these tests for
DWARFv4 on Linux by adjusting the manual index. As part of the change we
unXFAILed these tests for DWARFv4 on all platforms. However, the manual
index isn't used on macOS so they're still broken. This patch reverts
the XFAIL on Darwin for DWARFv4.
Example CI failure:
```
FAIL: test_inline_static_members_dwarf4_dsym (TestConstStaticIntegralMember.TestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1769, in test_method
return attrvalue(self)
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 153, in test_inline_static_members_dwarf4
self.check_inline_static_members("-gdwarf-4")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 129, in check_inline_static_members
self.check_global_var("A::int_val", "const int", "1")
File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py", line 118, in check_global_var
self.assertGreaterEqual(len(var_list), 1)
AssertionError: 0 not greater than or equal to 1
```
|
|
Added by https://github.com/llvm/llvm-project/pull/111859
Due to:
https://lab.llvm.org/buildbot/#/builders/141/builds/3691
This is not uncommon with DWARF testing on Windows. We may be
discarding the required information during linking.
I will look into it next week.
|
|
variables in DWARF 4 and earlier (#111859)
In DWARF 4 and earlier `static const` members of structs, classes and
unions have an entry tag `DW_TAG_member`, and are also tagged as
`DW_AT_declaration`, but otherwise follow the same rules as
`DW_TAG_variable`.
|
|
|
|
These tests started passing after this PR landed:
https://github.com/llvm/llvm-project/pull/74580
|
|
data-members" (#74580)
This commit reverts the changes in
https://github.com/llvm/llvm-project/pull/71780 and all of its follow-up
patches.
We got reports of the `.debug_names/.debug_gnu_pubnames/gdb_index/etc.`
sections growing by a non-trivial amount for some large projects. While
GCC emits definitions for static data member constants into the Names
index, they do so *only* for explicitly `constexpr` members. We were
indexing *all* constant-initialized const-static members, which is
likely where the significant size difference comes from. However, only
emitting explicitly `constexpr` variables into the index doesn't seem
like a good way forward, since from clang's perspective `const`-static
integrals are `constexpr` too, and that shouldn't be any different in
the debug-info component. Also, as new code moves to `constexpr` instead
of `const` static for constants, such solution would just delay the
growth of the Names index.
To prevent the size regression we revert to not emitting definitions for
static data-members that have no location.
To support access to such constants from LLDB we'll most likely have to
have to make LLDB find the constants by looking at the containing class
first.
|
|
global variables (#73707)
In https://github.com/llvm/llvm-project/pull/73626 we started attaching
`DW_AT_const_value`s on a static data-member's declaration again. In
DWARFv5, those static members are represented with a `DW_TAG_variable`.
When LLDB builds the `ManualDWARFIndex`, it simply iterates over all
DIEs in a CU and puts *any* `DW_TAG_variable` with a constant or
location into the index. So when using the manual index, we can end up
having 2 entries for a static data member in the index, one for the
declaration and one for the definition.
This caused a test failure on Linux (where DWARFv5 is the default and
the tests use the manual index).
This patch loosens the restriction that we find exactly 1 variable.
|
|
`638a8393615e911b729d5662096f60ef49f1c65e` removed the `dsym`
condition for older compiler versions which caused the `dwarf`
variants tests to XPASS. This patch reverts to only XFAIL-ing
the `dsym` variant.
`15c80852028ff4020b3f85ee13ad3a2ed4bce3be` added
`test_shadowed_static_inline_members` which isn't supported
on older compiler versions.
|
|
defintion if available" (#71800)
This patch relands https://github.com/llvm/llvm-project/pull/71004 which
was reverted because the clang change it depends on was reverted.
In addition to the original patch, this PR includes a change to
`SymbolFileDWARF::ParseVariableDIE` to support CU-level variable
definitions that don't have locations, but represent a constant value.
Previously, when debug-maps were available, we would assume that a
variable with "static lifetime" (which in this case means "has a linkage
name") has a valid address, which isn't the case for non-locationed
constants. We could omit this additional change if we stopped attaching
linkage names to global non-locationed constants.
Original commit message:
"""
https://github.com/llvm/llvm-project/pull/71780 proposes moving the
`DW_AT_const_value` on inline static members from the declaration DIE to
the definition DIE. This patch makes sure the LLDB's expression
evaluator can continue to support static initialisers even if the
declaration doesn't have a `DW_AT_const_value` anymore.
Previously the expression evaluator would find the constant for a
VarDecl from its declaration `DW_TAG_member` DIE. In cases where the
initialiser was specified out-of-class, LLDB could find it during symbol
resolution.
However, neither of those will work for constants, since we don't have a
constant attribute on the declaration anymore and we don't have
constants in the symbol table.
"""
Depends on:
* https://github.com/llvm/llvm-project/pull/71780
|
|
members with constant initializers" (#71780)
This patch relands https://github.com/llvm/llvm-project/pull/70639
It was reverted because under certain conditions we triggered an
assertion
in `DIBuilder`. Specifically, in the original patch we called
`EmitGlobalVariable`
at the end of `CGDebugInfo::finalize`, after all the temporary `DIType`s
have
been uniqued. With limited debug-info such temporary nodes would be
created
more frequently, leaving us with non-uniqued nodes by the time we got to
`DIBuilder::finalize`; this violated its pre-condition and caused
assertions to trigger.
To fix this, the latest iteration of the patch moves
`EmitGlobalVariable` to the
beginning of `CGDebugInfo::finalize`. Now, when we create a temporary
`DIType` node as a result of emitting a variable definition, it will get
uniqued
in time. A test-case was added for this scenario.
We also now don't emit a linkage name for non-locationed constants since
LLDB doesn't make use of it anyway.
Original commit message:
"""
When an LLDB user asks for the value of a static data member, LLDB
starts
by searching the Names accelerator table for the corresponding variable
definition DIE. For static data members with out-of-class definitions
that
works fine, because those get represented as global variables with a
location
and making them eligible to be added to the Names table. However,
in-class
definitions won’t get indexed because we usually don't emit global
variables
for them. So in DWARF we end up with a single `DW_TAG_member` that
usually holds the constant initializer. But we don't get a corresponding
CU-level `DW_TAG_variable` like we do for out-of-class definitions.
To make it more convenient for debuggers to get to the value of inline
static data
members, this patch makes sure we emit definitions for static variables
with
constant initializers the same way we do for other static variables.
This also aligns
Clang closer to GCC, which produces CU-level definitions for inline
statics and also
emits these into `.debug_pubnames`.
The implementation keeps track of newly created static data members.
Then in `CGDebugInfo::finalize`, we emit a global `DW_TAG_variable` with
a
`DW_AT_const_value` for any of those declarations that didn't end up
with a
definition in the `DeclCache`.
The newly emitted `DW_TAG_variable` will look as follows:
```
0x0000007b: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("Foo")
...
0x0000008d: DW_TAG_member
DW_AT_name ("i")
DW_AT_type (0x00000062 "const int")
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_const_value (4)
Newly added
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
0x0000009a: DW_TAG_variable
DW_AT_specification (0x0000008d "i")
DW_AT_const_value (4)
DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
```
This patch also drops the `DW_AT_const_value` off of the declaration
since we
now always have it on the definition. This ensures that the
`DWARFParallelLinker`
can type-merge class with static members where we couldn't attach the
constant
on the declaration in some CUs.
"""
Dependent changes:
* https://github.com/llvm/llvm-project/pull/71800
|
|
static data members with constant initializers (#70639)""
This casued asserts:
llvm/lib/IR/Metadata.cpp:689:
void llvm::MDNode::resolve(): Assertion `isUniqued() && "Expected this to be uniqued"' failed.
See comments on the PR.
This also reverts the dependent follow-up commits, see below.
> When an LLDB user asks for the value of a static data member, LLDB
> starts by searching the Names accelerator table for the corresponding
> variable definition DIE. For static data members with out-of-class
> definitions that works fine, because those get represented as global
> variables with a location and making them eligible to be added to the
> Names table. However, in-class definitions won<E2><80><99>t get indexed because
> we usually don't emit global variables for them. So in DWARF we end
> up with a single `DW_TAG_member` that usually holds the constant
> initializer. But we don't get a corresponding CU-level
> `DW_TAG_variable` like we do for out-of-class definitions.
>
> To make it more convenient for debuggers to get to the value of
> inline static data members, this patch makes sure we emit definitions
> for static variables with constant initializers the same way we do
> for other static variables. This also aligns Clang closer to GCC,
> which produces CU-level definitions for inline statics and also
> emits these into `.debug_pubnames`.
>
> The implementation keeps track of newly created static data members.
> Then in `CGDebugInfo::finalize`, we emit a global `DW_TAG_variable`
> with a `DW_AT_const_value` for any of those declarations that didn't
> end up with a definition in the `DeclCache`.
>
> The newly emitted `DW_TAG_variable` will look as follows:
> ```
> 0x0000007b: DW_TAG_structure_type
> DW_AT_calling_convention (DW_CC_pass_by_value)
> DW_AT_name ("Foo")
> ...
>
> 0x0000008d: DW_TAG_member
> DW_AT_name ("i")
> DW_AT_type (0x00000062 "const int")
> DW_AT_external (true)
> DW_AT_declaration (true)
> DW_AT_const_value (4)
>
> Newly added
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
>
> 0x0000009a: DW_TAG_variable
> DW_AT_specification (0x0000008d "i")
> DW_AT_const_value (4)
> DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
> ```
>
> This patch also drops the `DW_AT_const_value` off of the declaration
> since we now always have it on the definition. This ensures that the
> `DWARFParallelLinker` can type-merge class with static members where
> we couldn't attach the constant on the declaration in some CUs.
This reverts commit 7c3707aea8a6f1fc245ad2862982b8a51b6c0fea.
This reverts commit cab0a19467ac2e6e1e022087f4b6cb90d55da040.
This reverts commit 317481b3c8b34b0c3f106c514e6aa39b70886110.
This reverts commit 15fc809404d4715822e5349b76dcca50eb100eec.
This reverts commit 470de2bbec7f5fdd199775aa99c68ac76f4d5c74.
|
|
Juding by https://lab.llvm.org/buildbot/#/builders/219/builds/6774/steps/6/logs/stdio
this is passing now.
|
|
This is a newly added test which XPASSes on Linux
|
|
data members (#70641)"
Tests that LLDB can find inline static data members.
Relies on the debug-info change in:
https://github.com/llvm/llvm-project/pull/70639
|
|
defintion if available (#71004)"
https://github.com/llvm/llvm-project/pull/70639 proposes moving the
`DW_AT_const_value` on inline static members from the declaration DIE to
the definition DIE. This patch makes sure the LLDB's expression
evaluator can continue to support static initialisers even if the
declaration doesn't have a `DW_AT_const_value` anymore.
Previously the expression evaluator would find the constant for a
VarDecl from its declaration `DW_TAG_member` DIE. In cases where the
initialiser was specified out-of-class, LLDB could find it during symbol
resolution.
However, neither of those will work for constants, since we don't have a
constant attribute on the declaration anymore and we don't have
constants in the symbol table.
**Testing**
* If https://github.com/llvm/llvm-project/pull/70639 were to land
without this patch then most of the `TestConstStaticIntegralMember.py`
would start failing
|
|
members with constant initializers (#70639)"
When an LLDB user asks for the value of a static data member, LLDB
starts by searching the Names accelerator table for the corresponding
variable definition DIE. For static data members with out-of-class
definitions that works fine, because those get represented as global
variables with a location and making them eligible to be added to the
Names table. However, in-class definitions won’t get indexed because
we usually don't emit global variables for them. So in DWARF we end
up with a single `DW_TAG_member` that usually holds the constant
initializer. But we don't get a corresponding CU-level
`DW_TAG_variable` like we do for out-of-class definitions.
To make it more convenient for debuggers to get to the value of
inline static data members, this patch makes sure we emit definitions
for static variables with constant initializers the same way we do
for other static variables. This also aligns Clang closer to GCC,
which produces CU-level definitions for inline statics and also
emits these into `.debug_pubnames`.
The implementation keeps track of newly created static data members.
Then in `CGDebugInfo::finalize`, we emit a global `DW_TAG_variable`
with a `DW_AT_const_value` for any of those declarations that didn't
end up with a definition in the `DeclCache`.
The newly emitted `DW_TAG_variable` will look as follows:
```
0x0000007b: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("Foo")
...
0x0000008d: DW_TAG_member
DW_AT_name ("i")
DW_AT_type (0x00000062 "const int")
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_const_value (4)
Newly added
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
0x0000009a: DW_TAG_variable
DW_AT_specification (0x0000008d "i")
DW_AT_const_value (4)
DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
```
This patch also drops the `DW_AT_const_value` off of the declaration
since we now always have it on the definition. This ensures that the
`DWARFParallelLinker` can type-merge class with static members where
we couldn't attach the constant on the declaration in some CUs.
|
|
members with constant initializers (#70639)"
This reverts commit 4909814c08fdf4ec8bd9dad4f157d03de7c3c800.
Following LLDB patch had to be reverted due to Linux test failures:
```
ef3febadf606c2fc4f1ad8d85a7ecdde16e4cbb3
```
Since without that LLDB patch the LLDB tests would fail, revert
this clang patch for now.
|
|
defintion if available (#71004)"
This reverts commit ef3febadf606c2fc4f1ad8d85a7ecdde16e4cbb3.
This caused an LLDB test failure on Linux for `lang/cpp/symbols/TestSymbols.test_dwo`:
```
make: Leaving directory '/home/worker/2.0.1/lldb-x86_64-debian/build/lldb-test-build.noindex/lang/cpp/symbols/TestSymbols.test_dwo'
runCmd: expression -- D::i
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. HandleCommand(command = "expression -- D::i")
1. <user expression 0>:1:4: current parser token 'i'
2. <lldb wrapper prefix>:44:1: parsing function body '$__lldb_expr'
3. <lldb wrapper prefix>:44:1: in compound statement ('{}')
Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
0 _lldb.cpython-39-x86_64-linux-gnu.so 0x00007fbcfcb08b87
1 _lldb.cpython-39-x86_64-linux-gnu.so 0x00007fbcfcb067ae
2 _lldb.cpython-39-x86_64-linux-gnu.so 0x00007fbcfcb0923f
3 libpthread.so.0 0x00007fbd07ab7140
```
And a failure in `TestCallStdStringFunction.py` on Linux aarch64:
```
--
Exit Code: -11
Command Output (stdout):
--
lldb version 18.0.0git (https://github.com/llvm/llvm-project.git revision ef3febadf606c2fc4f1ad8d85a7ecdde16e4cbb3)
clang revision ef3febadf606c2fc4f1ad8d85a7ecdde16e4cbb3
llvm revision ef3febadf606c2fc4f1ad8d85a7ecdde16e4cbb3
--
Command Output (stderr):
--
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. HandleCommand(command = "expression str")
1. <lldb wrapper prefix>:45:34: current parser token ';'
2. <lldb wrapper prefix>:44:1: parsing function body '$__lldb_expr'
3. <lldb wrapper prefix>:44:1: in compound statement ('{}')
#0 0x0000ffffb72a149c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_[lldb.cpython-38-aarch64-linux-gnu.so](http://lldb.cpython-38-aarch64-linux-gnu.so/)+0x58c749c)
#1 0x0000ffffb729f458 llvm::sys::RunSignalHandlers() (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_[lldb.cpython-38-aarch64-linux-gnu.so](http://lldb.cpython-38-aarch64-linux-gnu.so/)+0x58c5458)
#2 0x0000ffffb72a1bd0 SignalHandler(int) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_[lldb.cpython-38-aarch64-linux-gnu.so](http://lldb.cpython-38-aarch64-linux-gnu.so/)+0x58c7bd0)
#3 0x0000ffffbdd9e7dc (linux-vdso.so.1+0x7dc)
#4 0x0000ffffb71799d8 lldb_private::plugin::dwarf::SymbolFileDWARF::FindGlobalVariables(lldb_private::ConstString, lldb_private::CompilerDeclContext const&, unsigned int, lldb_private::VariableList&) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_[lldb.cpython-38-aarch64-linux-gnu.so](http://lldb.cpython-38-aarch64-linux-gnu.so/)+0x579f9d8)
#5 0x0000ffffb7197508 DWARFASTParserClang::FindConstantOnVariableDefinition(lldb_private::plugin::dwarf::DWARFDIE) (/home/tcwg-buildbot/worker/lldb-aarch64-ubuntu/build/lib/python3.8/site-packages/lldb/_[lldb.cpython-38-aarch64-linux-gnu.so](http://lldb.cpython-38-aarch64-linux-gnu.so/)+0x57bd508)
```
|
|
data members (#70641)"
This reverts commit 934c573b7d24327fafea916a1d0e9a9fc88f87ab.
We had to revert dependencies of this patch due to test failures
on Linux:
```
4909814c08fdf4ec8bd9dad4f157d03de7c3c800
ef3febadf606c2fc4f1ad8d85a7ecdde16e4cbb3
```
|
|
available (#71004)
https://github.com/llvm/llvm-project/pull/70639 proposes moving the
`DW_AT_const_value` on inline static members from the declaration DIE to
the definition DIE. This patch makes sure the LLDB's expression
evaluator can continue to support static initialisers even if the
declaration doesn't have a `DW_AT_const_value` anymore.
Previously the expression evaluator would find the constant for a
VarDecl from its declaration `DW_TAG_member` DIE. In cases where the
initialiser was specified out-of-class, LLDB could find it during symbol
resolution.
However, neither of those will work for constants, since we don't have a
constant attribute on the declaration anymore and we don't have
constants in the symbol table.
**Testing**
* If https://github.com/llvm/llvm-project/pull/70639 were to land
without this patch then most of the `TestConstStaticIntegralMember.py`
would start failing
|
|
members (#70641)
Tests that LLDB can find inline static data members.
Relies on the debug-info change in:
https://github.com/llvm/llvm-project/pull/70639
|
|
with constant initializers (#70639)
When an LLDB user asks for the value of a static data member, LLDB
starts by
searching the Names accelerator table for the corresponding variable
definition
DIE. For static data members with out-of-class definitions that works
fine,
because those get represented as global variables with a location and
making them
eligible to be added to the Names table. However, in-class definitions
won’t get
indexed because we usually don't emit global variables for them. So in
DWARF
we end up with a single `DW_TAG_member` that usually holds the constant
initializer.
But we don't get a corresponding CU-level `DW_TAG_variable` like we do
for
out-of-class definitions.
To make it more convenient for debuggers to get to the value of inline
static data members,
this patch makes sure we emit definitions for static variables with
constant initializers
the same way we do for other static variables. This also aligns Clang
closer to GCC, which
produces CU-level definitions for inline statics and also emits these
into `.debug_pubnames`.
The implementation keeps track of newly created static data members.
Then in
`CGDebugInfo::finalize`, we emit a global `DW_TAG_variable` with a
`DW_AT_const_value` for
any of those declarations that didn't end up with a definition in the
`DeclCache`.
The newly emitted `DW_TAG_variable` will look as follows:
```
0x0000007b: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("Foo")
...
0x0000008d: DW_TAG_member
DW_AT_name ("i")
DW_AT_type (0x00000062 "const int")
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_const_value (4)
Newly added
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
0x0000009a: DW_TAG_variable
DW_AT_specification (0x0000008d "i")
DW_AT_const_value (4)
DW_AT_linkage_name ("_ZN2t2IiE1iIfEE")
```
This patch also drops the `DW_AT_const_value` off of the declaration since we now always have it on the definition. This ensures that the `DWARFParallelLinker` can type-merge class with static members where we couldn't attach the constant on the declaration in some CUs.
|
|
The error message "Couldn't lookup symbols" emitted from IRExecutionUnit
is grammatically incorrect. "Lookup" is noun when spelled without a
space. Update the error message to use the verb "look up" instead.
|
|
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
|
|
**Summary**
The public lldb matrix bot is failing for tests compiled with clang-9, clang-11, clang-13.
This patch addresses these failures by evaluating the enum case that
doesn't cause malformed DWARF in older version of clang.
There was no particular reason we had to use `true` enum case
to reproduce the bug in #58383, so simply switch to use `false`
to get all bots passing again.
**Details**
In older versions of clang, the following snippet:
```
enum EnumBool : bool {
enum_bool_case1 = false,
enum_bool_case2 = true,
};
struct A {
const static EnumBool enum_bool_val = enum_bool_case2;
};
```
…results in following DWARF:
```
0x00000052: DW_TAG_structure_type
DW_AT_calling_convention (DW_CC_pass_by_value)
DW_AT_name ("A")
DW_AT_byte_size (0x01)
DW_AT_decl_file ("/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/repro.cpp")
DW_AT_decl_line (6)
0x0000005b: DW_TAG_member
DW_AT_name ("enum_bool_val")
DW_AT_type (0x0000000000000068 "const EnumBool")
DW_AT_decl_file ("/Users/michaelbuch/Git/llvm-project/lldb/test/API/lang/cpp/const_static_integral_member/repro.cpp")
DW_AT_decl_line (7)
DW_AT_external (true)
DW_AT_declaration (true)
DW_AT_const_value (-1)
```
Note the `DW_AT_const_value == -1`
When evaluating `A::enum_bool_val` in the lldb we get:
```
(lldb) p A::enum_bool_val
error: expression failed to parse:
error: Couldn't lookup symbols:
__ZN1A13enum_bool_valE
```
Enabling the DWARF logs we see:
```
(arm64) clang-13.out: DWARFASTParserClang::ParseTypeFromDWARF (die = 0x00000068, decl_ctx = 0x136ac1e30 (die 0x0000000b)) DW_TAG_const_type name = '(null)')
Failed to add const value to variable A::enum_bool_val: Can't store unsigned value 18446744073709551615 in integer with 1 bits.
```
This occurs because a boolean enum is considered an unsigned integer
type, but we try to initialize it with a `-1`.
**Testing**
- Confirmed locally that top-of-tree lldb correctly
evaluates the previously failing expression when
the test program is compiled with clang-13
Differential Revision: https://reviews.llvm.org/D137793
|
|
type
Undoes a lot of the code added in D135169 to piggyback off of the enum logic in `TypeSystemClang::SetIntegerInitializerForVariable()`.
Fixes #58383.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D137045
|
|
Similar to D135170.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D135461
|
|
Previously we had a bit of a mix of "signed char" "unsigned char" and
"char".
This adds seperate min and max checks for all three types.
Depends on D135170
Reviewed By: Michael137
Differential Revision: https://reviews.llvm.org/D135352
|
|
As with static bool for whatever reason printing them on their own
worked fine but wasn't handled when you printed the whole type.
I don't see a good way to test this from clang's side so our existing
tests will have to do.
We can now print all of the struct "A", so there's no need for a separate
one for static bool testing. I've not checked the output, just that it
succeeds. This saves us having to handle different min/max between systems.
Depends on D135169
Reviewed By: aeubanks, shafik
Differential Revision: https://reviews.llvm.org/D135170
|
|
Fixes #58135
Somehow lldb was able to print the member on its own but when we try
to print the whole type found by "image lookup -t" lldb would crash.
This is because we'd encoded the initial value of the member as an integer.
Which isn't the end of the world because bool is integral for C++.
However, clang has a special AST node to handle literal bool and it
expected us to use that instead.
This adds a new codepath to handle static bool which uses cxxBoolLiteralExpr
and we get the member printed as you'd expect.
For testing I added a struct with just the bool because trying to print
all of "A" crashes as well. Presumably because one of the other member's
types isn't handled properly either.
So for now I just added the bool case, we can merge it with A later.
Reviewed By: aeubanks
Differential Revision: https://reviews.llvm.org/D135169
|
|
dsym variant
This test fails for Clang versions < 14.0 for `dsym` variants.
`dsymutil` strips debug info for classes with only static members.
Thus move the failing assertions into the XFAIL test case.
Differential Revision: https://reviews.llvm.org/D132004
|
|
1438639a2f7eb9e9cba01454d3a9b1b16d179c9a removed a test
that was using undefined behaviour setting a non-typed enum
to a value outside its known range.
That test also checked if we formatted the value properly
when it could contain >1 valid enum value.
I don't think there's anything special about how we format
typed vs non-typed enums so I'm adding a test for ScopedEnum
that will expect to see 2 enum values plus extra.
Reviewed By: labath, Michael137, shafik
Differential Revision: https://reviews.llvm.org/D131472
|
|
Setting an enum without a fixed underlying type to a value which is outside the
value range is undefined behavior.
The initializer needs to be a constant expression and therefore this was always
ill-formed we just were not diagnosing it before.
See D130058 and D131307 for more details.
Differential Revision: https://reviews.llvm.org/D131460
|
|
`IntegerLiteral::Create` operates on integer types. For that reason
when we parse DWARF into an AST, when we encounter a constant
initialized enum member variable, we try to determine the underlying
integer type before creating the `IntegerLiteral`. However, we
currently don't desugar the type and for enum typedefs
`dyn_cast<EnumType>` fails. In debug builds this triggers following
assert:
```
Assertion failed: (type->isIntegerType() && "Illegal type in IntegerLiteral"), function IntegerLiteral, file Expr.cpp, line 892
```
This patch turns the `dyn_cast<EnumType>` into a `getAs<EnumType>`
which `dyn_cast`s the canonical type, allowing us to get to the
underlying integer type.
**Testing**
* API test
* Manual repro is fixed
Differential Revision: https://reviews.llvm.org/D130213
|
|
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.
|
|
the expression evaluator"
This reverts commit 486787210df5ce5eabadc90a7de353ae81101feb.
This broke the windows lldb bot: https://lab.llvm.org/buildbot/#/builders/83/builds/21186
|
|
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
|
