Fix miscompilations for debugger because of resilience #78728
Conversation
This patch fixes two instances of the compiler embedded in LLDB miscompiling code for expression evaluation, because of a combination of the debugger's access to private types and resilience, which would cause the generated code to access fields indirectly through resilience functions that were never emitted. rdar://137876089
|
@swift-ci test |
|
@adrian-prantl on #78486 you said that this should be testable but I'm not sure how? We'd somehow have to access a private type on a different module to emulate lldb's behavior, which I don't I don't think is possible (LLDB does that by overriding |
|
I'm adding some lldb tests though |
|
@swift-ci test |
1 similar comment
|
@swift-ci test |
| !classDecl->getASTContext().LangOpts.DebuggerSupport || | ||
| methodAccess == AccessLevel::Public; | ||
| if (IGM.hasResilientMetadata(classDecl, ResilienceExpansion::Maximal) && | ||
| shouldUseDispatchThunkIfInDebugger) { |
There was a problem hiding this comment.
Can this be tested by compiling Swift code to IR and passing -debugger-support?
There was a problem hiding this comment.
I tried that but it's not enough. To look up private classes LLDB implements the DebuggerClient interface, without that we can't write a test that can extend a non-public type in a different module, to emulate LLDB's behavior.
|
@swift-ci test Linux |
| // level of the getter to decide whether to use a dispatch thunk for the | ||
| // debugger. | ||
| bool shouldUseDispatchThunkIfInDebugger = | ||
| !classDecl->getASTContext().LangOpts.DebuggerSupport || |
This patch fixes two instances of the compiler embedded in LLDB miscompiling code for the debugger's expression evaluation, because of a combination of the debugger's access to private types and resilience, which would cause the generated code to access fields indirectly through resilience functions that were never emitted.
rdar://137876089