[lldb] Make sure triple and SDK always match. #9728
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
Author
|
@swift-ci test |
adrian-prantl
requested review from
JDevlieghere,
augusto2112 and
kastiglione
adrian-prantl
force-pushed
the
141173613
branch
from
6875624 to
e990795
Compare
Author
|
@swift-ci test |
adrian-prantl
force-pushed
the
141173613
branch
from
e990795 to
b099233
Compare
Author
|
@swift-ci test |
JDevlieghere
approved these changes
Dec 13, 2024
Comment on lines
+2900
to
+2905
There was a problem hiding this comment.
Is this too noisy to report as a Diagnostic? This seems pretty valuable and something we could deduplicate at the Module level perhaps?
Author
There was a problem hiding this comment.
In my first draft, I had this as Debugger::ReportWarning. But the problem I see is that it could be really hard to associate the warning with the action that triggered it. You get the warning when the first Swift type system in that SymbolContext is initialized, but that might be triggered by, eg., your IDE's variable view.
Author
|
@swift-ci test linux |
This is particularly important in simulator processes, when stopped in a symbol context that has no Swift, or no debug info, for example in libsystem_kernel. In that case we used to take the precise triple from the dylib (which would be macosx, not ios-simulator). Since we don’t find debug info in the current dylib we would select the SDK from the first dylib with debug info, which is ios-simulator. This patch avoids this situation by 1. preferring the target triple if there is no Swift debug info 2. ensuring that the SDK always matches the triple rdar://141173613
adrian-prantl
force-pushed
the
141173613
branch
from
b099233 to
9bc04d3
Compare
Author
|
@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.
This is particularly important in simulator processes, when stopped in a symbol context that has no Swift, or no debug info, for example in libsystem_kernel. In that case we used to take the precise triple from the dylib (which would be macosx, not ios-simulator). Since we don’t find debug info in the current dylib we would select the SDK from the first dylib with debug info, which is ios-simulator.
This patch avoids this situation by
rdar://141173613