<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Nick,<br>
<br>
On 9/20/2013 8:37 PM, Nick Kledzik wrote:<br>
</div>
<blockquote
cite="mid:5CB804E7-A7F9-4A88-9252-E664ACFCA9D4@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>Shankar,</div>
<div><br>
</div>
<div>I think your proposal and mine are pretty much the same. The
difference is passing back info to the InputGraph as a parameter
in nextFile() vs as a separate method call. My original draft
email had a parameter in nextFile(), but it seemed a little
confusing because the information was referring to the previous
file. That is, if the current resolver state has
newDefinedAtoms, that really means the last file (returned by
nextFile()) caused new atoms to be added. </div>
<div><br>
</div>
<div>In your ResolverState you have bits for all the kinds of
atoms added. Is all that needed? I think all the InputGraph
needs to know is if the last file was used. A group is scanned
repeatedly until there is one complete pass in which no new
files were used. <br>
</div>
</blockquote>
Yes just bits, to say whether it was used and contributed undefined
atoms or Defined Weak atoms.<br>
<blockquote
cite="mid:5CB804E7-A7F9-4A88-9252-E664ACFCA9D4@apple.com"
type="cite">
<div><br>
</div>
<div>Also, is nextFile() going to be in InputGraph and directly
accessed by the Resolver? Or is nextFile in LinkingContext
(which forwards it to the InputGraph)? I assume the later.</div>
</blockquote>
<br>
Yes the latter.<br>
<blockquote
cite="mid:5CB804E7-A7F9-4A88-9252-E664ACFCA9D4@apple.com"
type="cite">
<div><br>
</div>
<div>Currently, the Resolver has buildInitialAtomList() and
resolveUndefines() which matches the way darwin links. I assume
part of this change is to unify those two methods by just have
one loop that uses nextFile().</div>
<div><br>
</div>
</blockquote>
Yes. This also makes the resolver totally dependent on
InputGraph/LinkingContext.<br>
<br>
<blockquote
cite="mid:5CB804E7-A7F9-4A88-9252-E664ACFCA9D4@apple.com"
type="cite">
<div>Given that nextFile() is basically an iteration mechanism,
perhaps we can make it conform to C++11 iterators.</div>
</blockquote>
<br>
Yes, its an iterator. I was thinking on a second pass around the
same. nextFile could work on a range of files, until it reaches a
ControlNode in the InputGraph.<br>
<br>
<blockquote
cite="mid:5CB804E7-A7F9-4A88-9252-E664ACFCA9D4@apple.com"
type="cite">
<div> The one issue is the feedback of whether the file was used
or not. A separate notifyFileAddedContent() method (instead of
a parameter to nextFile()) could fix that. And if
Resolver::doFile() called
linkingContext.notifyFileAddedContent() for every file used
(even object files), then the Resolver algorithm would look
like:</div>
</blockquote>
<br>
I like notifyFileAddedContent. makes it more extendable and can be
called from anywhere in the resolver after the call from nextFile.<br>
<br>
I will start implementing this solution. make<br>
Thanks<br>
<br>
Shankar Easwaran<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>