<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Dec 9, 2014 at 1:33 AM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/7/2014 7:19 PM, Rui Ueyama wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Dec 5, 2014 at 9:13 AM, Shankar Easwaran <<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>><br>
wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Rui,<br>
<br>
They key idea was to flatten the graph but also use tags to know about<br>
some control flags, that change linker operation(group begins / ends (or)<br>
what input files are part of as-needed).<br>
</blockquote></blockquote></span>
I think you missed addressing this issue, the writer needs to know where the group starts and where the group ends to print the Map file apppriately.<br>
<br>
I would prefer to use tags, or could you let me know what would be the alternative process other than going through the input elements twice.</blockquote><div><br></div><div>I don't disagree, and I think I didn't oppose to your suggestion. I was planning to create a "tag" (I don't know if I'm going to name the class as such though) to leave markers in a list of input files. The reason why I didn't do that in the previous patch is just to keep it small.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The LinkingContext would need to  know about what happens in the resolver<br>
per input element (that would contain a tag and a file locator).<br>
<br>
These two requirements are really needed for the linker Gnu flavor for its<br>
operation and the infrastructure needs to be scalable as well.<br>
<br>
</blockquote>
Yes, these are obvious needs. I have of course no intention to remove<br>
--as-needed from the linker.<br>
<br>
As you might have noticed, notifyProgress is not the only way that we can<br>
use for the core linker to the LinkingContext. It, for example, doesn't<br>
have to be real-time. Instead of telling the progress for each file, we<br>
could accumulate that information and pass it to the next pass.<br>
<br>
</blockquote></span>
While its possible in the current infrastructure to handle --as-needed,  I think we need to implement the necessary functions to call into the linking context or to query the resolver as part of this patch(as a replacement to notifyProgress).</blockquote><div><br></div><div>Yes, we need something as a replacement for notifyProgress. I think we are on the same page. And flattening the group is a first step.</div><div><br></div><div>Let's take an incremental approach as we planned. I have figured out the cause of the last breakage, so after testing it on Linux and MacOS, let me re-submit it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
Shankar Easwaran</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation<br>
<br>
</div></div></blockquote></div><br></div></div>