<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Thanks Ruiu, for putting this together.<br>
      <br>
      I like this proposal much, as it simplifies the resolver a lot and
      leaves it to the LinkingContext on how symbol resolution should
      happen.<br>
      <br>
      The Resolver will have a state <br>
      <br>
      enum ResolverState : uint8_t {<br>
           unChanged = 0x0,  // no change<br>
           newWeakAtoms = 0x1, // Found weak atoms<br>
           newUndefinedAtoms = 0x4, // Added new undefined atoms<br>
           newDefinedAtoms = 0x8, // Added new defined atoms<br>
           newAbsoluteAtoms = 0x10, // Added new absolute atoms<br>
           newSharedLibraryAtoms = 0x20, // Added new shared library
      atoms<br>
      };<br>
      <br>
      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.<br>
      <br>
      Thanks<br>
      <br>
      Shankar Easwaran<br>
      <br>
      On 9/20/2013 4:30 PM, Rui Ueyama wrote:<br>
    </div>
    <blockquote
cite="mid:CAJENXgtm72eGmWJzAH+18zhfTa4j7Cjx9jgG9UNYz95xW8EGjg@mail.gmail.com"
      type="cite">
      <pre wrap="">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.

</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a class="moz-txt-link-freetext" href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a>
<a class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation</pre>
  </body>
</html>