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

[Shankar Easwaran]

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