This is an archive of the discontinued LLVM Phabricator instance.

[lld] [mach-o]: Initial support for reading dylibs during link.
ClosedPublic

Authored by t.p.northover on Jun 26 2014, 8:41 AM.

Details

Summary

Hi,

The attached patch is my initial attempts to get lld to read .dylib files correctly during link. I mostly followed ELF, which seems to have the following effects:

+ No undefinedAtoms, definedAtoms etc
+ SharedLibraryAtoms are produced on demand (so not all exported symbols end up in the final image).
+ the sharedLibraryAtoms function returns an empty set (I'm not sure why this is. If anyone does know the reasoning, I'd be glad to hear it).

On the MachO specific side, experiments with ld64 suggest that all N_EXT (even N_PEXT) symbols that aren't N_UNDF are should be eligible to be resolved in the dylib.

Does it look reasonable as a first pass? Or should I change some things?

Cheers.

Tim.

Diff Detail

Event Timeline

t.p.northover retitled this revision from to [lld] [mach-o]: Initial support for reading dylibs during link..
t.p.northover updated this object.
t.p.northover edited the test plan for this revision. (Show Details)
t.p.northover added a reviewer: kledzik.
t.p.northover added a subscriber: Unknown Object (MLST).
kledzik added inline comments.Jun 26 2014, 12:08 PM
lib/ReaderWriter/MachO/Atoms.h
128

There is nothing to fix now. But long term, what we need to have happen is when the Resolver/SymbolTable replaces an UndefinedAtom with a SharedLibraryAtom, if the UndefinedAtom was marked canBeNullAtRuntime, then the SharedLibraryAtom needs to be marked that way too.

151

_dylib should be renamed _dylibInstallName. It is not the path where the dylib was loaded from (that might be in an SDK). It is the string from the dylib's LC_ID_DYLIB load command.

lib/ReaderWriter/MachO/File.h
100

Add FIXME note that we need to track whether a symbol is data or code to implement dataSymbolOnly correctly.

102–106

In the case where exports() has been called again with the same name, we should return the previously allocated atom (or assert). This code allocates another copy of the atom.

lib/ReaderWriter/MachO/MachONormalizedFileToAtoms.cpp
439–441

Probably should check visibility of symbol. In dylibs, only global symbols should be in globalSymbols. On the other hand, in .o files, hidden (scopeLinkageUnit) symbols are also in globalSymbols.

test/mach-o/lit.local.cfg
4 ↗(On Diff #10885)

Why the separate file for the dylib? You can put multiple yaml "documents" in one .yaml file. Just separate them with "---". That is one of the reasons for using yaml for test cases in lld.

You can also prune down that dylib yaml. It does not need content - just symbols.

Hi Nick,

Most of the comments seem fine, but...

+ for (auto &sym : normalizedFile.globalSymbols) {
+ file->addSharedLibraryAtom(sym.name, copyRefs);
+ }

+

Probably should check visibility of symbol. In dylibs, only global symbols should be in globalSymbols. On the other hand, in .o files, hidden (scopeLinkageUnit) symbols are also in globalSymbols.

Are you sure about this one? As far as I can tell, scopeLinkageUnit
corresponds to N_PEXT. I specifically ran some tests on .dylibs with
N_PEXT symbols and ld64 was quite happy to resolve them to that
.dylib. Did I cock up my tests, or are we talking about different
things?

Cheers.

Tim.

Hi Nick,

Hopefully this addresses your comments. Does it look more reasonable now?

Cheers.

Tim.

kledzik edited edge metadata.Jun 27 2014, 10:16 AM

LGTM.

I follow on patch would be to add support for install-name: key in dylib yaml files and plumb that to _dylibInstallName.

t.p.northover accepted this revision.Jun 30 2014, 2:22 AM
t.p.northover added a reviewer: t.p.northover.

Thanks Nick. Committed as r212027.

Tim.

This revision is now accepted and ready to land.Jun 30 2014, 2:22 AM
t.p.northover closed this revision.Jun 30 2014, 2:22 AM