llvm-project.git/lldb/test/API/lang/cpp, branch users/ojhunt/ptrauth-additions Unnamed repository; edit this file 'description' to name the repository. [lldb][test] Skip TestCppFloatingTypesSpecialization.py on older compilers 2025-10-10T13:54:24+00:00 Michael Buch michaelbuch12@gmail.com 2025-10-10T12:56:52+00:00 e18461a14eee06a1c83301a8b02d31ac4d275061 Fails with: ``` 08:19:28 /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/bin/clang++ -std=c++11 -g -O0 -isysroot "/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk" -arch arm64 -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/make/../../../../..//include -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/lldb-build/tools/lldb/include -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/make -include /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/make/test_common.h -fno-limit-debug-info -nostdlib++ -nostdinc++ -cxx-isystem /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/include/c++/v1/ --driver-mode=g++ -MT main.o -MD -MP -MF main.d -c -o main.o /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization/main.cpp 08:19:28 /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization/main.cpp:3:24: error: __bf16 is not supported on this target 08:19:28 template <> struct Foo<__bf16> {}; 08:19:28 ^ 08:19:28 /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization/main.cpp:5:40: error: __bf16 is not supported on this target 08:19:28 template <> struct Foo<_Float16> : Foo<__bf16> {}; 08:19:28 ^ 08:19:28 /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization/main.cpp:8:7: error: __bf16 is not supported on this target 08:19:28 Foo<__bf16> f0; 08:19:28 ^ 08:19:28 3 errors generated. 08:19:28 make: *** [main.o] Error 1 ``` On our Clang-15.0 CI. 
Fails with:
```
08:19:28  /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/bin/clang++  -std=c++11 -g -O0 -isysroot "/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk" -arch arm64  -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/make/../../../../..//include -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/lldb-build/tools/lldb/include -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization -I/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/make -include /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/make/test_common.h  -fno-limit-debug-info    -nostdlib++ -nostdinc++ -cxx-isystem /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/include/c++/v1/  --driver-mode=g++ -MT main.o -MD -MP -MF main.d -c -o main.o /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization/main.cpp
08:19:28  /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization/main.cpp:3:24: error: __bf16 is not supported on this target
08:19:28  template <> struct Foo<__bf16> {};
08:19:28                         ^
08:19:28  /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization/main.cpp:5:40: error: __bf16 is not supported on this target
08:19:28  template <> struct Foo<_Float16> : Foo<__bf16> {};
08:19:28                                         ^
08:19:28  /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/cpp/floating-types-specialization/main.cpp:8:7: error: __bf16 is not supported on this target
08:19:28    Foo<__bf16> f0;
08:19:28        ^
08:19:28  3 errors generated.
08:19:28  make: *** [main.o] Error 1
```

On our Clang-15.0 CI.
[lldb][test] TestExprDefinitionInDylib.py adjust test to account for older compiler versions 2025-10-02T13:08:40+00:00 Michael Buch michaelbuch12@gmail.com 2025-10-02T13:05:31+00:00 faf070f062ac7f3861092ab110982a613d7dfe1b Skip tests that require `-gstructor-decl-linkage-names` on Clang versions that don't support it. Don't pass `-gno-structor-decl-linkage-names` on Clang versions where it the flag didn't exist but it was the default behaviour of the compiler anyway. Drive-by: - We used to run `self.expect("Bar()")` which would always fail. So the `error=True` would be true even if we didn't pass the `-gno-structor-linkage-names`. So it wasn't testing the behaviour properly. This patch changes these to `self.expect("expr Bar()")`. 
 Skip tests that require `-gstructor-decl-linkage-names` on Clang versions that don't support it.

 Don't pass `-gno-structor-decl-linkage-names` on Clang versions where it the flag didn't exist but it was the default behaviour of the compiler anyway.

Drive-by:
- We used to run `self.expect("Bar()")` which would always fail. So the `error=True` would be true even if we didn't pass the `-gno-structor-linkage-names`. So it wasn't testing the behaviour properly. This patch changes these to `self.expect("expr Bar()")`.
[lldb][test] TestAbiTagStructors.py adjust test to account for older compiler versions 2025-10-02T12:48:46+00:00 Michael Buch michaelbuch12@gmail.com 2025-10-02T12:40:23+00:00 82b3057a5ec552d5e42bb595c8243e4fac0c70b4 Skip tests that require `-gstructor-decl-linkage-names` on Clang versions that don't support it. Don't pass `-gno-structor-decl-linkage-names` on Clang versions where it the flag didn't exist but it was the default behaviour of the compiler anyway. 
Skip tests that require `-gstructor-decl-linkage-names` on Clang
versions that don't support it.

Don't pass `-gno-structor-decl-linkage-names` on Clang versions where it
the flag didn't exist but it was the default behaviour of the compiler
anyway.
[lldb][test] TestStructuredBinding.py: adjust assertion to check for compatible compiler version 2025-10-02T12:33:21+00:00 Michael Buch michaelbuch12@gmail.com 2025-10-02T12:33:21+00:00 7e6d277d3bd10bacc121962637c3c646866e2ca3 Requires a compiler with the changes in https://github.com/llvm/llvm-project/pull/122265 
Requires a compiler with the changes in https://github.com/llvm/llvm-project/pull/122265
[lldb][test] Fix bf16 test cases on Arm 32-bit (#161528) 2025-10-01T14:53:10+00:00 David Spickett david.spickett@linaro.org 2025-10-01T14:53:10+00:00 edb80a8d7fb2e1e29a4cb792148b4ffd441eb114 Fixes #157674 On ARM, the presence of a specific bf16 type in the AST is gated by: ``` bool ARMTargetInfo::hasBFloat16Type() const { // The __bf16 type is generally available so long as we have any fp registers. return HasBFloat16 || (FPU && !SoftFloat); } ``` And the target we use when evaluating symbols (derived from the program file, I think, haven't found it yet) does not enable any of this. This means that we fall back to __fp16. So for parts of the testing we just need to expect __fp16 instead, and others we need to skip because now a class looks like it inherits from itself. There's a proper fix here somewhere but I don't know what it is yet. 
Fixes #157674

On ARM, the presence of a specific bf16 type in the AST is gated by: 
```
bool ARMTargetInfo::hasBFloat16Type() const {
  // The __bf16 type is generally available so long as we have any fp registers.
  return HasBFloat16 || (FPU && !SoftFloat);
}
```

And the target we use when evaluating symbols (derived from the program
file, I think, haven't found it yet) does not enable any of this.

This means that we fall back to __fp16.

So for parts of the testing we just need to expect __fp16 instead, and
others we need to skip because now a class looks like it inherits from
itself.

There's a proper fix here somewhere but I don't know what it is yet.
 [lldb][TypeSystemClang] Added unique builtins types for __bf16 and _Float16 (#157674) 2025-10-01T10:20:58+00:00 Timur Golubovich timur.golubovich@syntacore.com 2025-10-01T10:20:58+00:00 0a0d4979935cc13ecafdb8c9b00dd74779651781 During debugging applization with __bf16 and _Float16 float types it was discovered that lldb creates the same CompilerType for them. This can cause an infinite recursion error, if one tries to create two struct specializations with these types and then inherit one specialization from another. 
During debugging applization with __bf16 and _Float16 float types it was
discovered that lldb creates the same CompilerType for them. This can
cause an infinite recursion error, if one tries to create two struct
specializations with these types and then inherit one specialization
from another.
 [lldb][IRExecutionUnit] Return error on failure to resolve function address (#161363) 2025-10-01T07:37:15+00:00 Michael Buch michaelbuch12@gmail.com 2025-10-01T07:37:15+00:00 332b4deb0dfe9f4d11325513d4122e69024beea9 Starting with https://github.com/llvm/llvm-project/pull/148877 we started encoding the module ID of the function DIE we are currently parsing into its `AsmLabel` in the AST. When the JIT asks LLDB to resolve our special mangled name, we would locate the module and resolve the function/symbol we found in it. If we are debugging with a `SymbolFileDWARFDebugMap`, the module ID we encode is that of the `.o` file that is tracked by the debug-map. To resolve the address of the DIE in that `.o` file, we have to ask `SymbolFileDWARFDebugMap::LinkOSOAddress` to turn the address of the `.o` DIE into a real address in the linked executable. This will only work if the `.o` address was actually tracked by the debug-map. However, if the function definition appears in multiple `.o` files (which is the case for functions defined in headers), the linker will most likely de-deuplicate that definition. So most `.o`'s definition DIEs for that function won't have a contribution in the debug-map, and thus we fail to resolve the address. When debugging Clang on Darwin, e.g., you'd see: ``` (lldb) expr CXXDecl->getName() error: Couldn't look up symbols: $__lldb_func::0x1:0x4000d000002359da:_ZNK5clang9NamedDecl7getNameEv Hint: The expression tried to call a function that is not present in the target, perhaps because it was optimized out by the compiler. ``` unless you were stopped in the `.o` file whose definition of `getName` made it into the final executable. The fix here is to error out if we fail to resolve the address, causing us to fall back on the old flow which did a lookup by mangled name, which the `SymbolFileDWARFDebugMap` will handle correctly. An alternative fix to this would be to encode the `SymbolFileDWARFDebugMap`'s module-id. And implement `SymbolFileDWARFDebugMap::ResolveFunctionCallLabel` by doing a mangled name lookup. The proposed approach doesn't stop us from implementing that, so we could choose to do it in a follow-up. rdar://161393045 
Starting with https://github.com/llvm/llvm-project/pull/148877 we
started encoding the module ID of the function DIE we are currently
parsing into its `AsmLabel` in the AST. When the JIT asks LLDB to
resolve our special mangled name, we would locate the module and resolve
the function/symbol we found in it.

If we are debugging with a `SymbolFileDWARFDebugMap`, the module ID we
encode is that of the `.o` file that is tracked by the debug-map. To
resolve the address of the DIE in that `.o` file, we have to ask
`SymbolFileDWARFDebugMap::LinkOSOAddress` to turn the address of the
`.o` DIE into a real address in the linked executable. This will only
work if the `.o` address was actually tracked by the debug-map. However,
if the function definition appears in multiple `.o` files (which is the
case for functions defined in headers), the linker will most likely
de-deuplicate that definition. So most `.o`'s definition DIEs for that
function won't have a contribution in the debug-map, and thus we fail to
resolve the address.

When debugging Clang on Darwin, e.g., you'd see:
```
(lldb) expr CXXDecl->getName()

error: Couldn't look up symbols:
  $__lldb_func::0x1:0x4000d000002359da:_ZNK5clang9NamedDecl7getNameEv
Hint: The expression tried to call a function that is not present in the target, perhaps because it was optimized out by the compiler.
```
unless you were stopped in the `.o` file whose definition of `getName`
made it into the final executable.

The fix here is to error out if we fail to resolve the address, causing
us to fall back on the old flow which did a lookup by mangled name,
which the `SymbolFileDWARFDebugMap` will handle correctly.

An alternative fix to this would be to encode the
`SymbolFileDWARFDebugMap`'s module-id. And implement
`SymbolFileDWARFDebugMap::ResolveFunctionCallLabel` by doing a mangled
name lookup. The proposed approach doesn't stop us from implementing
that, so we could choose to do it in a follow-up.

rdar://161393045
 [clang][Expr] Teach IgnoreUnlessSpelledInSource about implicit calls to std::get free function (#122265) 2025-09-20T17:30:18+00:00 Michael Buch michaelbuch12@gmail.com 2025-09-20T17:30:18+00:00 012680faf4c63a9bd432aa92fa0da97981793ac3 When we generate the debug-info for a `VarDecl` we try to determine whether it was introduced as part of a structure binding (aka a "holding var"). If it was then we don't mark it as `artificial`. The heuristic to determine a holding var uses `IgnoreUnlessSpelledInSource` to unwrap the `VarDecl` initializer until we hit a `DeclRefExpr` that refers to a `Decomposition`. For "tuple-like decompositions", Clang will generate a call to a `template<size_t I> Foo get(Bar)` function that retrieves the `Ith` element from the tuple-like structure. If that function is a member function, we get an AST that looks as follows: ``` VarDecl implicit used z1 'std::tuple_element<0, B>::type &&' cinit `-ExprWithCleanups <col:10> 'int' xvalue `-MaterializeTemporaryExpr <col:10> 'int' xvalue extended by Var 0x11d110cf8 'z1' 'std::tuple_element<0, B>::type &&' `-CXXMemberCallExpr <col:10> 'int' `-MemberExpr <col:10> '<bound member function type>' .get 0x11d104390 `-ImplicitCastExpr <col:10> 'B' xvalue <NoOp> `-DeclRefExpr <col:10> 'B' lvalue Decomposition 0x11d1100a8 '' 'B' ``` `IgnoreUnlessSpelledInSource` happily unwraps this down to the `DeclRefExpr`. However, when the `get` helper is a free function (which it is for `std::pair` in libc++ for example), then the AST is: ``` VarDecl col:16 implicit used k 'std::tuple_element<0, const std::tuple<int, int>>::type &' cinit `-CallExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type':'const int' lvalue adl |-ImplicitCastExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type &(*)(const tuple<int, int> &) noexcept' <FunctionToPointerDecay> | `-DeclRefExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type &(const tuple<int, int> &) noexcept' lvalue Function 0x1210262d8 'get' 'const typename tuple_element<0UL, tuple<int, int>>::type &(const tuple<int, int> &) noexcept' (FunctionTemplate 0x11d068088 'get') `-DeclRefExpr <col:16> 'const std::tuple<int, int>' lvalue Decomposition 0x121021518 '' 'const std::tuple<int, int> &' ``` `IgnoreUnlessSpelledInSource` doesn't unwrap this `CallExpr`, so we incorrectly mark the binding as `artificial` in debug-info. This patch adjusts `IgnoreUnlessSpelledInSource` so it unwraps implicit `CallExpr`s. It's almost identical to how we treat implicit constructor calls (unfortunately the code can't quite be re-used because a `CXXConstructExpr` is-not a `CallExpr`, and we check `isElidable`, which doesn't exist for regular function calls. So I added a new `IgnoreImplicitCallSingleStep`). Fixes https://github.com/llvm/llvm-project/issues/122028 
When we generate the debug-info for a `VarDecl` we try to determine
whether it was introduced as part of a structure binding (aka a "holding
var"). If it was then we don't mark it as `artificial`.

The heuristic to determine a holding var uses
`IgnoreUnlessSpelledInSource` to unwrap the `VarDecl` initializer until
we hit a `DeclRefExpr` that refers to a `Decomposition`. For "tuple-like
decompositions", Clang will generate a call to a `template<size_t I> Foo
get(Bar)` function that retrieves the `Ith` element from the tuple-like
structure. If that function is a member function, we get an AST that
looks as follows:
```
VarDecl implicit used z1 'std::tuple_element<0, B>::type &&' cinit
`-ExprWithCleanups <col:10> 'int' xvalue
  `-MaterializeTemporaryExpr <col:10> 'int' xvalue extended by Var 0x11d110cf8 'z1' 'std::tuple_element<0, B>::type &&'
    `-CXXMemberCallExpr <col:10> 'int'
      `-MemberExpr <col:10> '<bound member function type>' .get 0x11d104390
        `-ImplicitCastExpr <col:10> 'B' xvalue <NoOp>
          `-DeclRefExpr <col:10> 'B' lvalue Decomposition 0x11d1100a8 '' 'B'
```
`IgnoreUnlessSpelledInSource` happily unwraps this down to the
`DeclRefExpr`. However, when the `get` helper is a free function (which
it is for `std::pair` in libc++ for example), then the AST is:
```
VarDecl col:16 implicit used k 'std::tuple_element<0, const std::tuple<int, int>>::type &' cinit
`-CallExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type':'const int' lvalue adl
  |-ImplicitCastExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type &(*)(const tuple<int, int> &) noexcept' <FunctionToPointerDecay>
  | `-DeclRefExpr <col:16> 'const typename tuple_element<0UL, tuple<int, int>>::type &(const tuple<int, int> &) noexcept' lvalue Function 0x1210262d8 'get' 'const typename tuple_element<0UL, tuple<int, int>>::type &(const tuple<int, int> &) noexcept' (FunctionTemplate 0x11d068088 'get')
  `-DeclRefExpr <col:16> 'const std::tuple<int, int>' lvalue Decomposition 0x121021518 '' 'const std::tuple<int, int> &'
```
`IgnoreUnlessSpelledInSource` doesn't unwrap this `CallExpr`, so we
incorrectly mark the binding as `artificial` in debug-info.

This patch adjusts `IgnoreUnlessSpelledInSource` so it unwraps implicit
`CallExpr`s. It's almost identical to how we treat implicit constructor
calls (unfortunately the code can't quite be re-used because a
`CXXConstructExpr` is-not a `CallExpr`, and we check `isElidable`, which
doesn't exist for regular function calls. So I added a new
`IgnoreImplicitCallSingleStep`).

Fixes https://github.com/llvm/llvm-project/issues/122028
 [lldb][test] TestAbiTagStructors.py: XFAIL on Windows 2025-09-09T12:37:07+00:00 Michael Buch michaelbuch12@gmail.com 2025-09-09T12:34:53+00:00 6dfc255ee103fda23d14ef2765123dd34f646ccd This is failing on the lldb-aarch64-windows bots with (see error below). XFAIL for now because it's unlikely that these expression evaluator calls were supported before they were added. ``` ====================================================================== FAIL: test_nested_no_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_nested_no_structor_linkage_names_dwarf) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method return attrvalue(self) ^^^^^^^^^^^^^^^ File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 108, in test_nested_no_structor_linkage_names self.do_nested_structor_test() File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 102, in do_nested_structor_test self.expect( File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2453, in expect self.assertFalse( AssertionError: True is not false : Command 'expression TaggedLocal()' is expected to fail! Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe ====================================================================== FAIL: test_nested_with_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_nested_with_structor_linkage_names_dwarf) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method return attrvalue(self) ^^^^^^^^^^^^^^^ File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 112, in test_nested_with_structor_linkage_names self.do_nested_structor_test() File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 102, in do_nested_structor_test self.expect( File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2453, in expect self.assertFalse( AssertionError: True is not false : Command 'expression TaggedLocal()' is expected to fail! Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe ====================================================================== FAIL: test_no_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_no_structor_linkage_names_dwarf) Test that without linkage names on structor declarations we can't call ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method return attrvalue(self) ^^^^^^^^^^^^^^^ File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 81, in test_no_structor_linkage_names self.expect("expr Tagged t3(t1)", error=True) File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2453, in expect self.assertFalse( AssertionError: True is not false : Command 'expr Tagged t3(t1)' is expected to fail! Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe ====================================================================== FAIL: test_with_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_with_structor_linkage_names_dwarf) ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method return attrvalue(self) ^^^^^^^^^^^^^^^ File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 20, in test_with_structor_linkage_names self.expect_expr( File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2596, in expect_expr value_check.check_value(self, eval_result, str(eval_result)) File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 301, in check_value test_base.assertSuccess(val.GetError()) File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2631, in assertSuccess self.fail(self._formatMessage(msg, "'{}' is not success".format(error))) AssertionError: 'error: Internal error [IRForTarget]: Result variable (??__F$__lldb_expr_result@?1??$__lldb_expr@@YAXPEAX@Z@YAXXZ) is defined, but is not a global variable ``` 
This is failing on the lldb-aarch64-windows bots with (see error below).
XFAIL for now because it's unlikely that these expression evaluator
calls were supported before they were added.

```
======================================================================

FAIL: test_nested_no_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_nested_no_structor_linkage_names_dwarf)

----------------------------------------------------------------------

Traceback (most recent call last):

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method

    return attrvalue(self)

           ^^^^^^^^^^^^^^^

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 108, in test_nested_no_structor_linkage_names

    self.do_nested_structor_test()

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 102, in do_nested_structor_test

    self.expect(

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2453, in expect

    self.assertFalse(

AssertionError: True is not false : Command 'expression TaggedLocal()' is expected to fail!

Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe

======================================================================

FAIL: test_nested_with_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_nested_with_structor_linkage_names_dwarf)

----------------------------------------------------------------------

Traceback (most recent call last):

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method

    return attrvalue(self)

           ^^^^^^^^^^^^^^^

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 112, in test_nested_with_structor_linkage_names

    self.do_nested_structor_test()

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 102, in do_nested_structor_test

    self.expect(

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2453, in expect

    self.assertFalse(

AssertionError: True is not false : Command 'expression TaggedLocal()' is expected to fail!

Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe

======================================================================

FAIL: test_no_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_no_structor_linkage_names_dwarf)

    Test that without linkage names on structor declarations we can't call

----------------------------------------------------------------------

Traceback (most recent call last):

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method

    return attrvalue(self)

           ^^^^^^^^^^^^^^^

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 81, in test_no_structor_linkage_names

    self.expect("expr Tagged t3(t1)", error=True)

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2453, in expect

    self.assertFalse(

AssertionError: True is not false : Command 'expr Tagged t3(t1)' is expected to fail!

Config=aarch64-C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\build\bin\clang.exe

======================================================================

FAIL: test_with_structor_linkage_names_dwarf (TestAbiTagStructors.AbiTagStructorsTestCase.test_with_structor_linkage_names_dwarf)

----------------------------------------------------------------------

Traceback (most recent call last):

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 1828, in test_method

    return attrvalue(self)

           ^^^^^^^^^^^^^^^

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\test\API\lang\cpp\abi_tag_structors\TestAbiTagStructors.py", line 20, in test_with_structor_linkage_names

    self.expect_expr(

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2596, in expect_expr

    value_check.check_value(self, eval_result, str(eval_result))

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 301, in check_value

    test_base.assertSuccess(val.GetError())

  File "C:\Users\tcwg\llvm-worker\lldb-aarch64-windows\llvm-project\lldb\packages\Python\lldbsuite\test\lldbtest.py", line 2631, in assertSuccess

    self.fail(self._formatMessage(msg, "'{}' is not success".format(error)))

AssertionError: 'error: Internal error [IRForTarget]: Result variable (??__F$__lldb_expr_result@?1??$__lldb_expr@@YAXPEAX@Z@YAXXZ) is defined, but is not a global variable

```
[lldb][Expression] Add structor variant to LLDB's function call labels (#149827) 2025-09-09T09:02:00+00:00 Michael Buch michaelbuch12@gmail.com 2025-09-09T09:02:00+00:00 57a790717937af52db8c97d3666dc76487bd4226 Depends on * https://github.com/llvm/llvm-project/pull/148877 * https://github.com/llvm/llvm-project/pull/155483 * https://github.com/llvm/llvm-project/pull/155485 * https://github.com/llvm/llvm-project/pull/154137 * https://github.com/llvm/llvm-project/pull/154142 This patch is an implementation of [this discussion](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816/7) about handling ABI-tagged structors during expression evaluation. **Motivation** LLDB encodes the mangled name of a `DW_TAG_subprogram` into `AsmLabel`s on function and method Clang AST nodes. This means that when calls to these functions get lowered into IR (when running JITted expressions), the address resolver can locate the appropriate symbol by mangled name (and it is guaranteed to find the symbol because we got the mangled name from debug-info, instead of letting Clang mangle it based on AST structure). However, we don't do this for `CXXConstructorDecl`s/`CXXDestructorDecl`s because these structor declarations in DWARF don't have a linkage name. This is because there can be multiple variants of a structor, each with a distinct mangling in the Itanium ABI. Each structor variant has its own definition `DW_TAG_subprogram`. So LLDB doesn't know which mangled name to put into the `AsmLabel`. Currently this means using ABI-tagged structors in LLDB expressions won't work (see [this RFC](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816) for concrete examples). **Proposed Solution** The `FunctionCallLabel` encoding that we put into `AsmLabel`s already supports stuffing more info about a DIE into it. So this patch extends the `FunctionCallLabel` to contain an optional discriminator (a sequence of bytes) which the `SymbolFileDWARF` plugin interprets as the constructor/destructor variant of that DIE. So when searching for the definition DIE, LLDB will include the structor variant in its heuristic for determining a match. There's a few subtleties here: 1. At the point at which LLDB first constructs the label, it has no way of knowing (just by looking at the debug-info declaration), which structor variant the expression evaluator is supposed to call. That's something that gets decided when compiling the expression. So we let the Clang mangler inject the correct structor variant into the `AsmLabel` during JITing. I adjusted the `AsmLabelAttr` mangling for this in https://github.com/llvm/llvm-project/pull/155485. An option would've been to create a new Clang attribute which behaved like an `AsmLabel` but with these special semantics for LLDB. My main concern there is that we'd have to adjust all the `AsmLabelAttr` checks around Clang to also now account for this new attribute. 2. The compiler is free to omit the `C1` variant of a constructor if the `C2` variant is sufficient. In that case it may alias `C1` to `C2`, leaving us with only the `C2` `DW_TAG_subprogram` in the object file. Linux is one of the platforms where this occurs. For those cases I added a heuristic in `SymbolFileDWARF` where we pick `C2` if we asked for `C1` but it doesn't exist. This may not always be correct (e.g., if the compiler decided to drop `C1` for other reasons). 3. In https://github.com/llvm/llvm-project/pull/154142 Clang will emit `C4`/`D4` variants of ctors/dtors on declarations. When resolving the `FunctionCallLabel` we will now substitute the actual variant that Clang told us we need to call into the mangled name. We do this using LLDB's `ManglingSubstitutor`. That way we find the definition DIE exactly the same way we do for regular function calls. 4. In cases where declarations and definitions live in separate modules, the DIE ID encoded in the function call label may not be enough to find the definition DIE in the encoded module ID. For those cases we fall back to how LLDB used to work: look up in all images of the target. To make sure we don't use the unified mangled name for the fallback lookup, we change the lookup name to whatever mangled name the FunctionCallLabel resolved to. rdar://104968288 
Depends on
* https://github.com/llvm/llvm-project/pull/148877
* https://github.com/llvm/llvm-project/pull/155483
* https://github.com/llvm/llvm-project/pull/155485
* https://github.com/llvm/llvm-project/pull/154137
* https://github.com/llvm/llvm-project/pull/154142

This patch is an implementation of [this
discussion](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816/7)
about handling ABI-tagged structors during expression evaluation.

**Motivation**

LLDB encodes the mangled name of a `DW_TAG_subprogram` into `AsmLabel`s
on function and method Clang AST nodes. This means that when calls to
these functions get lowered into IR (when running JITted expressions),
the address resolver can locate the appropriate symbol by mangled name
(and it is guaranteed to find the symbol because we got the mangled name
from debug-info, instead of letting Clang mangle it based on AST
structure). However, we don't do this for
`CXXConstructorDecl`s/`CXXDestructorDecl`s because these structor
declarations in DWARF don't have a linkage name. This is because there
can be multiple variants of a structor, each with a distinct mangling in
the Itanium ABI. Each structor variant has its own definition
`DW_TAG_subprogram`. So LLDB doesn't know which mangled name to put into
the `AsmLabel`.

Currently this means using ABI-tagged structors in LLDB expressions
won't work (see [this
RFC](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816)
for concrete examples).

**Proposed Solution**

The `FunctionCallLabel` encoding that we put into `AsmLabel`s already
supports stuffing more info about a DIE into it. So this patch extends
the `FunctionCallLabel` to contain an optional discriminator (a sequence
of bytes) which the `SymbolFileDWARF` plugin interprets as the
constructor/destructor variant of that DIE. So when searching for the
definition DIE, LLDB will include the structor variant in its heuristic
for determining a match.

There's a few subtleties here:
1. At the point at which LLDB first constructs the label, it has no way
of knowing (just by looking at the debug-info declaration), which
structor variant the expression evaluator is supposed to call. That's
something that gets decided when compiling the expression. So we let the
Clang mangler inject the correct structor variant into the `AsmLabel`
during JITing. I adjusted the `AsmLabelAttr` mangling for this in
https://github.com/llvm/llvm-project/pull/155485. An option would've
been to create a new Clang attribute which behaved like an `AsmLabel`
but with these special semantics for LLDB. My main concern there is that
we'd have to adjust all the `AsmLabelAttr` checks around Clang to also
now account for this new attribute.
2. The compiler is free to omit the `C1` variant of a constructor if the
`C2` variant is sufficient. In that case it may alias `C1` to `C2`,
leaving us with only the `C2` `DW_TAG_subprogram` in the object file.
Linux is one of the platforms where this occurs. For those cases I added
a heuristic in `SymbolFileDWARF` where we pick `C2` if we asked for `C1`
but it doesn't exist. This may not always be correct (e.g., if the
compiler decided to drop `C1` for other reasons).
3. In https://github.com/llvm/llvm-project/pull/154142 Clang will emit
`C4`/`D4` variants of ctors/dtors on declarations. When resolving the
`FunctionCallLabel` we will now substitute the actual variant that Clang
told us we need to call into the mangled name. We do this using LLDB's
`ManglingSubstitutor`. That way we find the definition DIE exactly the
same way we do for regular function calls.
4. In cases where declarations and definitions live in separate modules,
the DIE ID encoded in the function call label may not be enough to find
the definition DIE in the encoded module ID. For those cases we fall
back to how LLDB used to work: look up in all images of the target. To
make sure we don't use the unified mangled name for the fallback lookup,
we change the lookup name to whatever mangled name the FunctionCallLabel
resolved to.

rdar://104968288