[LLVMdev] [lld] [mach-o]: RFC: representing LC_REEXPORT_DYLIB

[Nick Kledzik]

On Jul 1, 2014, at 7:35 AM, Tim Northover <t.p.northover at gmail.com> wrote:

> Hi all,
> 
> I've been thinking about how best to represent MachO's
> LC_REEXPORT_DYLIB (used even by libSystem.dylib to provide its various
> sub-components[*]).
> 
> It looks like this functionality would naturally fall into the
> InputGraph, in analogy with Groups and Archives. Unfortunately, it's
> rather more dynamic than the existing cases: we don't know the needed
> files before parsing the top-level one, and need to open multiple
> files. Essentially, we'd need to create new MachOFileNodes based on
> the contents of the parent.
> 
> It seems there are two obvious ways to do this:
> 
> 1. Create them while we still have the MachONormalizedFile around; I
> think this would mean extending the InputGraph::parse interface to
> allow new InputNodes to be passed back.
ld64 does it in two phases.  The first phase just loads the dylibs directly
specified on the command line.  The second phase loads any
“indirect” dylibs.  

Perhaps at the end of DarwinLdDriver::parse() after the nodes are created
for all the command line files, the driver can iterate over the nodes and
instantiate any indirect dylibs needed?    You don’t want to load the
indirect dylibs as each direct dylib is loaded because one of the indirect
ones may later turn out to be a direct one, and the order determines
the two-level-namespace ordinal used which we want to remain deterministic. 

In ld64 the processing of indirect dylibs has two purposes: 1) to support
LC_REEXPORT_DYLIB, 2) to support flat_namespace linking of a
main executable wherein the linker must check all undefines in all
dylibs are resolved.  

The second case is also needed for ELF linkers (—no-allow-shilb-undefined)
which means an ELF linker would need to load indirect dylibs too.  

Shankar, Does lld for ELF support loading indirect DSOs?

-Nick


> 2. Add an atom type to represent the dependency and create the actual
> nodes when we get back to MachOFileNode::parse.
> 
> I'm still very new to lld, so which of these fits in better with our
> goals? Or has someone else already thought about it and have a cunning
> plan? I'm happy to implement anyone's idea if it's the neatest way to
> go.
> 
> Cheers.
> 
> Tim.
> 
> [*] It's the last barrier to "lld -flavor darwin -arch x86_64
> -macosx_version_min 10.9 hello_world.o /usr/lib/libSystem.dylib
> -ohello_world" working, I think! Using
> /usr/lib/system/libsystem_c.dylib already does.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev