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
```
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
The original PR has been reverted because of an LLDB test failure. This patch now works around the test failure by simply allowing the new symbols to show up in a stack trace. This reverts commit 72c04bb882ad70230bce309c3013d9cc2c99e9a7. Original commit message: This patch replaces `__can_extract_key` with an overload set to try to extract the key. This simplifies the code, since we don't need to have separate overload sets for the unordered and associative containers. It also allows extending the set of extraction cases more easily, since we have a single place to define how the key is extracted.
This patch works around an assertion that we hit in the `LambdaExpr` constructor when we call it from `ASTNodeImporter::VisitLambdaExpr` (see https://github.com/llvm/llvm-project/issues/149477). The lambda that we imported doesn't have the `NumCaptures` field accurately set to the one on the source decl. This is because in `MinimalImport` mode, we skip importing of lambda definitions: https://github.com/llvm/llvm-project/blob/e21b0dd81928a3266df0e3ede008fb7a6676ff95/clang/lib/AST/ASTImporter.cpp#L2499 In practice we have seen this assertion occur in our `import-std-module` test-suite when libc++ headers decide to use lambdas inside inline function bodies (the latest failure being caused by https://github.com/llvm/llvm-project/pull/144602). To avoid running into this whenever libc++ decides to use lambdas in headers, this patch skips `ASTImport` of lambdas alltogether. Ideally this would bubble up to the user or log as an error, but we swallow the `ASTImportError`s currently. The only way this codepath is hit is when lambdas are used inside functions in defined in the expression evaluator, or when importing AST nodes from Clang modules. Both of these are very niche use-cases (for now), so a workaround seemed appropriate.
Introduces `_regexp-step`, a step command which additionally allows for
stepping into a target function. This change updates `step` and `s` to
be aliases for `_regexp-step`.
The existing `sif` alias ("Step Into Function") is not well known
amongst users. This change updates `step` and `s` to also work like
`sif`, taking an optional function name.
This is implemented to not break uses of `step` or `s` with a flag, for
example running `step -r func_to_avoid` works as expected.
This fixes a few bugs, effectively through a fallback to `p` when `po` fails. The motivating bug this fixes is when an error within the compiler causes `po` to fail. Previously when that happened, only its value (typically an object's address) was printed – and problematically, no compiler diagnostics were shown. With this change, compiler diagnostics are shown, _and_ the object is fully printed (ie `p`). Another bug this fixes is when `po` is used on a type that doesn't provide an object description (such as a struct). Again, the normal `ValueObject` printing is used. Additionally, this also improves how lldb handles an object description method that fails in some way. Now an error will be shown (it wasn't before), and the value will be printed normally.
Fixes a bug that surfaces in frame recognizers. Details about the bug: A new frame recognizer is configured to match a specific symbol (`swift_willThrow`). This is an `extern "C"` symbol defined in a C++ source file. When Swift is built with debug info, the function `ParseFunctionFromDWARF` will use the debug info to construct a function name that looks like a C++ declaration (`::swift_willThrow(void *, SwiftError**)`). The `Mangled` instance will have this string as its `m_demangled` field, and have _no_ string for its `m_mangled` field. The result is the frame recognizer would not match the symbol to the name (`swift_willThrow` != `::swift_willThrow(void *, SwiftError**)`. By changing `ParseFunctionFromDWARF` to assign both a demangled name and a mangled, frame recognizers can successfully match symbols in this configuration.
When I wrote this previously, I was unaware that the TLS function already adds the offset. The test was working previously because the offset was 0 in this case (only 1 thread-local variable). I added another thread-local variable to the test to make sure the offset is indeed handled correctly. rdar://156547548