Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-11485] Disabling -serialize-debugging-options breaks lldb Swift type loading #4481

Open
kastiglione opened this issue Sep 17, 2019 · 6 comments
Assignees
Labels
bug Something isn't working LLDB for Swift

Comments

@kastiglione
Copy link

Previous ID SR-11485
Radar rdar://problem/55479258
Original Reporter @kastiglione
Type Bug
Status Reopened
Resolution

Attachment: Download

Additional Detail from JIRA
Votes 1
Component/s LLDB for Swift
Labels Bug
Assignee @adrian-prantl
Priority Medium

md5: 66acdb4bc404bab42d7edf30fe14da67

Issue Description:

In order to use a build cache, we need to disable -serialize-debugging-options. Doing this prevents host specific paths from being embedded in .swiftmodule files.

However, disabling this breaks lldb's Swift AST resolution logic (I think). Specifically, Swift types, for example String, and Dictionary, are not resolved. This breaks expression evaluation and also printing values via frame variable.

Attached is a sample Xcode project. It has an xcconfig that sets two build settings:

SWIFT_SERIALIZE_DEBUGGING_OPTIONS = NO
OTHER_SWIFT_FLAGS = -Xfrontend -no-serialize-debugging-options

The first one tells Xcode to not add -Xfrontend -serialize-debugging-options.

The second one tells swiftc to always disable serialized debugging options. Without this flag, any module with a main entry point will automatically contain serialized debugging options.

The Xcode project has a breakpoint in the app delegate, that prints the launchOptions argument. The output is:

(lldb) p launchOptions
error: <EXPR>:3:1: error: use of unresolved identifier 'launchOptions'
launchOptions
^~~~~~~~~~~~~
@thii
Copy link

thii commented Jun 27, 2020

This doesn't seem to reproduce anymore with Xcode 11.5 and 12 beta. Is it fixed now?

@adrian-prantl
Copy link
Member

It is true that in Xcode 12, LLDB no longer reads the SDK out of the binary Swift modules, so if removing the paths from the Swift modules is what caused LLDB to no longer find the SDK, then that could be considered fixed.

@kastiglione
Copy link
Author

@thii thanks for the comment! In my testing with our project, we no longer need the work around for Xcode 11.5.

@keith
Copy link

keith commented Dec 18, 2020

I filed FB8943879 which I believe is this same issue but we only hit it when debugging XCTest bundles, not apps

@keith
Copy link

keith commented Mar 2, 2021

So at this point in test bundles I actually get:

error: <EXPR>:3:3: error: 'mutating' isn't valid on methods in classes or class-bound protocols
  mutating func $__lldb_wrapped_expr_1(_ $__lldb_arg : UnsafeMutablePointer<Any>) {
  ^~~~~~~~~
  

warning: <EXPR>:12:9: warning: initialization of variable '$__lldb_error_result' was never used; consider replacing with assignment to '_' or removing it
    var $__lldb_error_result = __lldb_tmp_error
    ~~~~^~~~~~~~~~~~~~~~~~~~
    _

when trying to `po self` when stopped in a XCTestCase. vo results in:

(lldb) vo self
self =

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 7, 2022
@keith
Copy link

keith commented Jun 10, 2022

So I figured out the issue in the XCTestCase reproduction case, really the issue was just a case of confusing errors, the error I posted above and the types log didn't really have any useful info, but in Swift 5.7 with swift-healthcheck I got this error:

SwiftASTContextForExpressions::LoadOneModule() -- Missing Swift module or Clang module found for "XCTest", "imported" via SwiftDWARFImporterDelegate. Hint: Register Swift modules with the linker using -add_ast_path.

Which immediately made me realize we were missing including the XCTest.framework path in the lldbinit. We're now setting:

settings set target.swift-framework-search-paths $TEST_FRAMEWORK_SEARCH_PATHS $FRAMEWORK_SEARCH_PATHS

Which appears to cover both unit tests and UI tests. Related bazelbuild/rules_swift#841 FB10167931

I think this can be closed unless we find more repro cases in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working LLDB for Swift
Projects
None yet
Development

No branches or pull requests

4 participants