From what I can tell, it's essentially identical to
-sub_library, but it doesn't match files ending in ".dylib".
Details
- Reviewers
thakis - Group Reviewers
Restricted Project - Commits
- rG8a5e06882336: [lld-macho] Support -sub_umbrella
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lgtm. Below is what I checked:
Doesn't sub_umbrella cause a different load command? (LC_SUB_UMBRELLA, sub_umbrella_command -- which admittedly has the same in-memory repr as sub_library_command, but the cmd id is different)
% touch foo.cc
% clang foo.cc -c
% clang -shared -o foo.dylib foo.o
% clang -shared -o bar.dylib foo.o -sub_umbrella foo.dylib foo.dylib
% otool -l bar.dylib | grep -C5 foo.dylib
cmdsize 16
version 0.0
Load command 9
cmd LC_REEXPORT_DYLIB
cmdsize 40
name foo.dylib (offset 24)
time stamp 2 Wed Dec 31 19:00:02 1969
current version 0.0.0
compatibility version 0.0.0
Load command 10
cmd LC_LOAD_DYLIB…no, it's just a LC_REEXPORT_DYLIB. Looking through ld64, that seems to match the handling there (but looking for it made me find -debug_snapshot / -snapshot_dir which I didn't know before. I guess that's like our --reproduce? If so, that'd be exciting! I'll add support for that spelling of --reproduce then, similar to how the coff port has both /reproduce: and /linkrepro:, the latter to match link.exe). So this looks correct.
There's a comment in ld64 that says
// target OS does not support LC_REEXPORT_DYLIB, so use old complicated load commands
So I guess that's what LC_SUB_{UMBRELLA, LIBRARY} are.