Skip to content

Fix the hardcoded Swift AST section / segment name for Mach-O #32362

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

Merged
merged 1 commit into from
Jun 15, 2020

Conversation

adrian-prantl
Copy link
Contributor

to match the one specified in LLVM's Mach-O parser.
Otherwise LLDB could not possibly find it!

This name is used by the swift -modulewrap subcommand, which is currently unused
on Darwin, and primarily intended for use under Linux. However, it may be useful
to better support static archives (.a) files with Swift debug info in the
future. To fully support this, dsymutil and LLDB need to know to look for Swift
AST sections in Mach-O objects other than .dSYM bundled.

Implementation note: It would be nice to get the section name out of libObject,
but with the current architecture this needs a major refactoring that didn't
seem justified, given that there is an end-to-end test to prevent such a mishap
in the future.

rdar://problem/63991514

to match the one specified in LLVM's Mach-O parser.
Otherwise LLDB could not possibly find it!

This name is used by the swift -modulewrap subcommand, which is currently unused
on Darwin, and primarily intended for use under Linux. However, it may be useful
to better support static archives (.a) files with Swift debug info in the
future. To fully support this, dsymutil and LLDB need to know to look for Swift
AST sections in Mach-O objects other than .dSYM bundled.

Implementation note: It would be nice to get the section name out of libObject,
but with the current architecture this needs a major refactoring that didn't
seem justified, given that there is an end-to-end test to prevent such a mishap
in the future.

<rdar://problem/63991514>
@adrian-prantl adrian-prantl requested review from vedantk and dcci June 13, 2020 01:08
@adrian-prantl
Copy link
Contributor Author

@swift-ci test

@compnerd
Copy link
Member

@swift-ci please test

@compnerd
Copy link
Member

@adrian-prantl - do we need to worry about compatibility? The older segment/section has shipped, so what do we do about existing binaries?

@adrian-prantl
Copy link
Contributor Author

@compnerd This patch only affects Mach-O, and LLDB is unable to find the section under this name. To my knowledge, no one is using -modulewrap on Darwin. In its place there is the ld64 -add_ast_path option. It may become useful to improve the workflow for static archives in the future, though.

@compnerd
Copy link
Member

Ah, awesome! I didn't know that -modulewrap wasn't in use on Darwin. Then I guess that my worry is nullified. (Yeah, I saw that it was MachO specific which is why I was worried about the compatibility story - ELF and COFF don't have to worry about that yet)

@adrian-prantl
Copy link
Contributor Author

@compnerd The backstory here is, I added -modulewrap specifically for Linux (Windows wasn't really a thing yet) because we don't control the ELF linker and ELF linkers store the debug info in the executable anyway.

@adrian-prantl adrian-prantl merged commit 403b2bf into swiftlang:master Jun 15, 2020
@vedantk
Copy link
Contributor

vedantk commented Jun 15, 2020

Thanks, looks good, we might consolidate some definitions into a shared header as a follow up.

@adrian-prantl
Copy link
Contributor Author

Thanks, looks good, we might consolidate some definitions into a shared header as a follow up.

I looked at that, and it's a massive refactoring for very little gain. I thought it would be nice to encode the section names in Dwarf.def, but there is so much extra data there, that I shied away from it. Doable, but quite a big patch.

Copy link
Member

@dcci dcci left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LG

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants