[lldb][swift] Create thread plan for stepping through Allocating Init #10576
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
felipepiovezan
force-pushed
the
felipe/fix-stepping-into-allocating-init
branch
from
33be91d to
345eddf
Compare
|
@swift-ci test |
|
@swift-ci test macos platform |
1 similar comment
|
@swift-ci test macos platform |
adrian-prantl
approved these changes
May 8, 2025
felipepiovezan
force-pushed
the
felipe/fix-stepping-into-allocating-init
branch
from
345eddf to
7f8c8bc
Compare
|
@swift-ci test |
These trampolines have a well defined target, which can be extracted from the demangle tree. A similar strategy is already adopted for stepping into conformance code. This allows LLDB to create a StepThrough plan with a target symbol, instead of a plan that keep taking steps until it reaches some interesting location. We already had a test for this, but we rely on the "step avoid libraries" setting to emulate the case of "avoid libraries without debug info". However, they are not exactly equivalent, so the test mislead us into believing stepping was working. A future patch should try to fold the setting-checking code into ThreadPlanShouldStopHere::DefaultShouldStopCallback. With this patch, the test now works regardless of whether debug info is present or not. To make this work, this commit also teaches the Swift language runtime how to recognize "type metadata accessors". These are thunks in the sense that they jump to some other code, but not user code. Their purposes is to eventually send the "self" message to the SwiftObject the first time they run. As such, they should just be stepped out from, which is accomplished by having the runtime recognize them as trampolines but not provide any specific actions, relying on the default behavior of ShouldStopHere. Prior to this change, this would sometimes work accidentally because all the functions involved had line 0 debug information, and the debugger would keep stepping through _all_ of them. However, in debug builds of x86, this strategy failed; sometimes the computed Symbol size is larger than the line entry for these functions, and so the detection "all line 0" fails. Relying on this is error-prone and slow, as it causes the debugger to stop many times.
felipepiovezan
force-pushed
the
felipe/fix-stepping-into-allocating-init
branch
from
7f8c8bc to
9503b80
Compare
|
@swift-ci test |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
These trampolines have a well defined target, which can be extracted from the demangle tree. A similar strategy is already adopted for stepping into conformance code. This allows LLDB to create a StepThrough plan with a target symbol, instead of a plan that keep taking steps until it reaches some interesting location.
We already had a test for this, but we rely on the "step avoid libraries" setting to emulate the case of "avoid libraries without debug info". However, they are not exactly equivalent, so the test mislead us into believing stepping was working. A future patch should try to fold the setting-checking code into
ThreadPlanShouldStopHere::DefaultShouldStopCallback.