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-14357] LLDB search path de-duplication can cause Swift debugging to fail #4317

Open
swift-ci opened this issue Mar 15, 2021 · 1 comment
Open
Labels
bug LLDB for Swift

Comments

@swift-ci
Copy link

@swift-ci swift-ci commented Mar 15, 2021

Previous ID SR-14357
Radar rdar://problem/75451184
Original Reporter richardh (JIRA User)
Type Bug
Additional Detail from JIRA
Votes 0
Component/s LLDB for Swift
Labels Bug
Assignee None
Priority Medium

md5: 4c0116d6b109c0cdf06ea245d1439391

Issue Description:

We have an issue in Xcode 12.5 where Swift applications will fail to debug as the search paths for some headers cannot be reconstructed. This is due to a recent change that de-duplicates header search paths when combining clang flags to create the Swift AST expression context. The issue we have is include paths like:

-Isome/path/to/headermap.hmap
-Isearch/path/for/hmap

Where the headermap contains paths of the form:

somelib/someheader.h -> path/relative/to/later/search/path/someheader.h

When resolving the relative destination path clang will search in subsequent include paths, but not prior ones. When we have multiple compilation commands with different headermap includes that rely on the same base path (this is a common case for Buck) the later base path includes will be skipped as they are already present in unique_flags. This will cause header lookups using those headermaps to fail.

I would be interested in thoughts on the best way to resolve this. We currently work around it by providing all the header map base paths through lldbinit config, but this is a bit messy. The other option I considered was moving duplicated search paths in the args to the end so as to preserve relative order between headermaps and search paths, which would work as long as conflicting headers cannot be found on earlier search paths (true in our case at least). Does this seem a reasonable approach?

@typesanitizer
Copy link

@typesanitizer typesanitizer commented Mar 15, 2021

@swift-ci create

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug LLDB for Swift
Projects
None yet
Development

No branches or pull requests

2 participants