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

Shankar Easwaran
Tue, 01 Jul 2014 16:25:24 -0000

Hi Tim,

Are you refererring to the dependencies of the dynamic library that
needs to be traversed, to resolve shared library atoms ?

You could build a Dynamic library node and have the symbol returned when
the shared library is called for a symbol, that needs to be resolved
using the below API.

const SharedLibraryAtom *exports(StringRef name, bool dataSymbolOnly)

Will this work ?

I think symbol resolution is more involved in MachO(from previous
conversations) with the current lld model, that symbols are resolved
from archive and dynamic libraries after all the object files are
processed too.

Will this simplify things ?

Thanks

Shankar Easwaran

On 7/1/2014 9:35 AM, Tim Northover 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.
> 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
>
>


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the
Linux Foundation