[LLVMdev] LLD input graph handling proposal

[Shankar Easwaran]

Thanks Ruiu, for putting this together.

I like this proposal much, as it simplifies the resolver a lot and 
leaves it to the LinkingContext on how symbol resolution should happen.

The Resolver will have a state

enum ResolverState : uint8_t {
      unChanged = 0x0,  // no change
      newWeakAtoms = 0x1, // Found weak atoms
      newUndefinedAtoms = 0x4, // Added new undefined atoms
      newDefinedAtoms = 0x8, // Added new defined atoms
      newAbsoluteAtoms = 0x10, // Added new absolute atoms
      newSharedLibraryAtoms = 0x20, // Added new shared library atoms
};

nextFile() can be renamed to nextFiles(), that would return a range of 
input files, makes it much easier to handle when there are no groups.

Thanks

Shankar Easwaran

On 9/20/2013 4:30 PM, Rui Ueyama wrote:
> Shankar and I discussed input file handling, and we came up with a design
> that may greatly simplify the input file handling, while giving more
> flexibility to developer to support complicated options, such as
> --{start,end}-group, -z rescan or -z rescan-now. It'd worth pursuing, so
> here's the idea:
>
> 1. We wouldn't probably want to let Resolver to handle the input graph
> directly, for we don't want to implement the details of input graph control
> node behavior for --{start,end}-group, -z rescan{,-now}, or whatever you
> define as a new linker option. Implementing it to Resolver would make it
> messy.
>
> 2. We would instead add a new method nextFile() to LinkingContext, which
> returns a new file from which Resolver should try to resolve undefined
> symbols. Resolver wouldn't handle the input graph at all. Instead, Resolver
> calls nextFile() repeatedly to link until nextFile() returns a null value.
>
> 3. Resolver will notify Linking Context when (A) all undefined symbols are
> resolved (success), or (B) it detects it's in an infinite loop in which it
> cannot resolve any symbols anymore (failure). Linking Context will do
> whatever it thinks appropriate for the event notification.
>
> So, with this mechanism, one can implement --{start,end}-group this way:
> Assume command line *--start-group a b c --end-group d.* nextFile() returns
> *a, b, c, a, b, c, a, ...* until it gets notified that Resolver cannot
> resolve symbol any longer. If notified, next call of nextFile() will return
> *d.* This is how "search the files in the group repeatedly until all
> possible references are resolved" is implemented.
>
> "-z rescan", which is an option to let the linker to reprocess all files up
> to the command line option position, can be implemented this way: Assume
> command line *a b -z rescan c*. nextFile() returns *a b a b c* in this
> order. That makes Resolver to reprocess file *a* and *b* twice.
>
> The logic for --whole-archive can also be implemented: Linking Context
> should usually return a null value for nextFile() if it gets notified all
> symbols are resolved in order to terminate Resolver. However, if
> --whole-archive option is given, it should continue to return new files to
> let Resolver to include all files appeared in the command line.
>
> Overall, this seems to be a clean API that is powerful enough to implement
> complex semantics.
>
>
>
> _______________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130920/9813e9fa/attachment.html>