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-14073] Support -modulewrap on Darwin #56462

Open
keith opened this issue Jan 20, 2021 · 3 comments
Open

[SR-14073] Support -modulewrap on Darwin #56462

keith opened this issue Jan 20, 2021 · 3 comments
Labels

Comments

@keith
Copy link
Collaborator

keith commented Jan 20, 2021

Previous ID SR-14073
Radar None
Original Reporter @keith
Type Task
Additional Detail from JIRA
Votes 0
Component/s
Labels Task
Assignee @keith
Priority Medium

md5: e39928bf062d3b315f2c632b516b1dd6

Issue Description:

Most of the infrastructure is there to support -modulewrap on Darwin. I went to enable the related test https://github.com/apple/swift/pull/34550/files and discovered that the linker doesn't add N_OSO symbols in the final binary for the modulewrap .o files. This seems to be because they don't have any symbols, so the linker ignores debug info from them.

I've made some progress (I think) towards making them usable by adding another symbol so the linker picks them up, but I'm worried that isn't actually the right path for this so I'm hoping I can get some advice here.

@keith
Copy link
Collaborator Author

keith commented Jan 20, 2021

@adrian-prantl if you have a few minutes to provide some pointers here that would be awesome!

@adrian-prantl
Copy link
Member

CC @JDevlieghere friss (JIRA User) @dcci.

If I recall correctly the linker will only generate N_OSO symbols for object files that contribute a function symbol to the executable. There are multiple ways to force the linker to pick up the file, such as adding a symbol to an export list or by ld -r-merging the modulewrap .o file with another object.

Can you remind me what the motivation for this is? Are you trying to improve the static archive (.a) workflow? I expect the best anser to depend on the exact use-case.

@keith
Copy link
Collaborator Author

keith commented Jan 20, 2021

I attempted the `-r` option as well, but it seems like the linker is a bit more strict than this and (in the most recent source dump) requires specific types of __DWARF sections https://github.com/michaeleisel/zld/blob/fa20ced5c682a40f1b6a3b2452407c73a0d267ef/ld/src/ld/OutputFile.cpp#L6725-L6726 that don't include the __swift_ast one https://github.com/michaeleisel/zld/blob/fa20ced5c682a40f1b6a3b2452407c73a0d267ef/ld/src/ld/parsers/macho_relocatable_file.cpp#L2527-L2536

The use case for us isn't super strong, originally we were hoping to use this solution to avoid ARG_MAX issues related to thousands of modules being added with -add_ast_path, but now with big sur bumping that number, this is less of an issue. But I figured since most of the infra already existed to support this on Darwin as well, I would try to take it to the finish line just in case another use case came up in the future.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@keith keith removed their assignment Mar 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants