🍒[lldb] Cherry-pick FunctionCallLabel support to 21.x #11298
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
@swift-ci test |
adrian-prantl
approved these changes
Sep 1, 2025
|
@swift-ci test |
…vm#150930) (cherry picked from commit c8a091e)
…vm#151355) Split out from llvm#148877 This patch prepares `TypeSystemClang` APIs to take `AsmLabel`s which concatenated strings (hence `std::string`) instead of a plain `const char*`. (cherry picked from commit 7410f6d)
…ction (llvm#151489) The ultimate goal is to replace the return types of all the `DWARFIndex` callbacks to `IterationAction`. To reduce the blast radius and do this incrementally I'm doing this for `GetFunctions` only here. I added a `IterationActionAdaptor` helper (that will ultimately get removed once all APIs have been migrated) to avoid having to change too many other APIs that `GetFunctions` interacts with. (cherry picked from commit 550058c)
…llvm#148877) LLDB currently attaches `AsmLabel`s to `FunctionDecl`s such that that the `IRExecutionUnit` can determine which mangled name to call (we can't rely on Clang deriving the correct mangled name to call because the debug-info AST doesn't contain all the info that would be encoded in the DWARF linkage names). However, we don't attach `AsmLabel`s for structors because they have multiple variants and thus it's not clear which mangled name to use. In the [RFC on fixing expression evaluation of abi-tagged structors](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816) we discussed encoding the structor variant into the `AsmLabel`s. Specifically in [this thread](https://discourse.llvm.org/t/rfc-lldb-handling-abi-tagged-constructors-destructors-in-expression-evaluator/82816/7) we discussed that the contents of the `AsmLabel` are completely under LLDB's control and we could make use of it to uniquely identify a function by encoding the exact module and DIE that the function is associated with (mangled names need not be enough since two identical mangled symbols may live in different modules). So if we already have a custom `AsmLabel` format, we can encode the structor variant in a follow-up (the current idea is to append the structor variant as a suffix to our custom `AsmLabel` when Clang emits the mangled name into the JITted IR). Then we would just have to teach the `IRExecutionUnit` to pick the correct structor variant DIE during symbol resolution. The draft of this is available [here](llvm#149827) This patch sets up the infrastructure for the custom `AsmLabel` format by encoding the module id, DIE id and mangled name in it. **Implementation** The flow is as follows: 1. Create the label in `DWARFASTParserClang`. The format is: `$__lldb_func:module_id:die_id:mangled_name` 2. When resolving external symbols in `IRExecutionUnit`, we parse this label and then do a lookup by DIE ID (or mangled name into the module if the encoded DIE is a declaration). Depends on llvm#151355 (cherry picked from commit f890591)
(cherry picked from commit a1a3254)
Currently failing with the following when building the test file: ``` C:\buildbot\as-builder-10\lldb-x86-64\build\bin\clang.exe lib.o -gdwarf -O0 -m64 -IC:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\packages\Python\lldbsuite\test\make/../../../../..//include -IC:/buildbot/as-builder-10/lldb-x86-64/build/tools/lldb/include -IC:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\test\API\lang\cpp\expr-definition-in-dylib -IC:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\packages\Python\lldbsuite\test\make -include C:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\packages\Python\lldbsuite\test\make/test_common.h -fno-limit-debug-info -fuse-ld=lld --driver-mode=g++ -shared -o "lib.dll" lld-link: warning: section name .debug_abbrev is longer than 8 characters and will use a non-standard string table lld-link: warning: section name .debug_info is longer than 8 characters and will use a non-standard string table lld-link: warning: section name .debug_line is longer than 8 characters and will use a non-standard string table lld-link: warning: section name .debug_str is longer than 8 characters and will use a non-standard string table C:\buildbot\as-builder-10\lldb-x86-64\build\bin\clang.exe main.o -L. -llib -gdwarf -O0 -m64 -IC:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\packages\Python\lldbsuite\test\make/../../../../..//include -IC:/buildbot/as-builder-10/lldb-x86-64/build/tools/lldb/include -IC:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\test\API\lang\cpp\expr-definition-in-dylib -IC:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\packages\Python\lldbsuite\test\make -include C:\buildbot\as-builder-10\lldb-x86-64\llvm-project\lldb\packages\Python\lldbsuite\test\make/test_common.h -fno-limit-debug-info -fuse-ld=lld --driver-mode=g++ -o "a.out" lld-link: error: undefined symbol: public: int __cdecl Foo::method(void) >>> referenced by main.o:(main) clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Makefile.rules:531: a.out] Error 1 make: Leaving directory 'C:/buildbot/as-builder-10/lldb-x86-64/build/lldb-test-build.noindex/lang/cpp/expr-definition-in-dylib/TestExprDefinitionInDylib.test' ``` Skip for now (cherry picked from commit 6d4a093)
…ows (again) (cherry picked from commit 96d1178)
These have been XPASSing after llvm#150022 (cherry picked from commit ebe6eba)
…o use IterationAction (llvm#151668) Continuation from llvm#151489 (cherry picked from commit 0bdb4a3)
This was added purely for the needs of LLDB. However, starting with llvm#151355 and llvm#148877 we no longer create literal AsmLabels in LLDB either. So this is unused and we can get rid of it. In the near future LLDB will want to add special support for mangling `AsmLabel`s (specifically llvm#149827). (cherry picked from commit cd8f348)
…m#151839) Continuation of llvm#151489 (cherry picked from commit 8d9afb8)
…lvm#151992) Continuation of llvm#151489 (cherry picked from commit 37b6fbc)
…llvm#152001) Continuation of llvm#151489 (cherry picked from commit 147cfc8)
…ionAction (llvm#152025) Continuation of llvm#151489 (cherry picked from commit d276569)
Now that all `DWARFIndex` APIs have been converted to use `IterationAction`, the `IterationActionAdaptor` is unused. (cherry picked from commit 4b31b4e)
Michael137
force-pushed
the
lldb/func-call-labels-to-21.x
branch
from
60c078b to
ad11337
Compare
|
@swift-ci test |
1 similar comment
|
@swift-ci test |
llvm#149490) The only place that passes a target to `LoadAddressResolver` already checks for pointer validity. And inside of the resolver we have been dereferencing the target anyway without nullptr checks. So codify the non-nullness of `m_target` by making it a reference. (cherry picked from commit 03b7766)
Michael137
force-pushed
the
lldb/func-call-labels-to-21.x
branch
from
41612b6 to
3e1d574
Compare
|
@swift-ci test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-picks llvm#148877 and related PRs to
stable/21.x