[LLVMdev] LLD input graph handling proposal

[Rui Ueyama]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130920/b13499ab/attachment.html>