It's roughly like -force_load with some filtering.
Details
- Reviewers
compnerd smeenai - Group Reviewers
Restricted Project - Commits
- rGcf918c809bb0: [lld-macho] Implement -ObjC
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
lld/MachO/ObjC.cpp | ||
---|---|---|
27 | Would you mind replacing 16 with sizeof(llvm::MachO::section::sectname) and sizeof(llvm::MachO::section::segname) respectively? |
LGTM
lld/MachO/Driver.cpp | ||
---|---|---|
254 | I don't think this'll cause any issues with actual usage, but I'll just note that this isn't strictly equivalent to forcing a load of the archive member with that symbol. For example, if you already had a symbol with the same name (e.g. from an object file that's already been processed), this implementation won't load the archive member containing that symbol, whereas I believe ld64 would (and give you a multiply defined symbol error). | |
264 | So we'd be adding ObjC-containing members twice, once as an ObjFile above and once as part of this archive? I don't think it'll cause any issues in practice, but it feels a little ugly conceptually. I think this is fine for now, but long-term it'd be nice to have something like LazyObjFile (like COFF and ELF do) to add each member only once (as either an ObjFile or a LazyObjFile). That would also address the TODO above and my previous comment. | |
lld/test/MachO/objc.s | ||
2 | Can you add an input archive with multiple members and show that only the member containing the Obj-C symbols/sections gets pulled in? Right now I think all the tests would pass if you replaced -ObjC with -all_load; I want a test which shows the difference between the two. |
address comments
lld/MachO/Driver.cpp | ||
---|---|---|
264 | yeah, that's true. I'll expand the TODO comment above to mention this. |
I don't think this'll cause any issues with actual usage, but I'll just note that this isn't strictly equivalent to forcing a load of the archive member with that symbol. For example, if you already had a symbol with the same name (e.g. from an object file that's already been processed), this implementation won't load the archive member containing that symbol, whereas I believe ld64 would (and give you a multiply defined symbol error).