<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 18, 2016 at 7:36 PM, Teresa Johnson <span dir="ltr"><<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Jul 18, 2016 at 7:02 PM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Jul 18, 2016 at 5:37 PM, Mehdi AMINI <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">mehdi_amini added a comment.<br>
<span><br>
In <a href="https://reviews.llvm.org/D22356#487800" rel="noreferrer" target="_blank">https://reviews.llvm.org/D22356#487800</a>, @tejohnson wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D22356#487784" rel="noreferrer" target="_blank">https://reviews.llvm.org/D22356#487784</a>, @mehdi_amini wrote:<br>
><br>
> > > That's a good question and an idea I thought about briefly but discarded for a couple reasons. I was concerned about requiring communication between the ThinLink and final link to build the link line (it would be more difficult to support in a build system, and also seems conceptually more complicated).<br>
> ><br>
> ><br>
> > How is the final link invocation computed right now?<br>
><br>
><br>
> The link line is essentially the same, but with native .o instead of the bitcode .o. (See the new test case for an example)<br>
<br>
<br>
</span>The question is: in the presence of static archives, how do you generates --start-lib/--end-lib? This seems to already require some build-system integration?<br></blockquote><div><br></div></span><div>There is one to one mapping from bitcode .o and native .o -- so the command line can be formed.</div><span><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> ><br>
<br>
><br>
<br>
> ><br>
<br>
><br>
<br>
> > > Also I'm not 100% convinced that removing the --start-lib/--end-lib, even if we only include those object files the linker decided to select symbols from, would result in the same linking behavior.<br>
<br>
><br>
<br>
> ><br>
<br>
><br>
<br>
> ><br>
<br>
><br>
<br>
> > Your observations about the linker picking different symbols seem to indicate that the --start-lib/--end-lib model is already broken.<br>
<br>
><br>
<br>
><br>
<br>
> When you say "is already broken" do you mean even in non-ThinLTO mode? I'm not sure why - it is just like having an archive of the objects between each start/end pair.<br>
<br>
<br>
</span>I'm only talking about ThinLTO and the two-stage linking, i.e. the second invocation of the linker does not end-up with the same prevailing resolution as the first invocation. Your current patches are working around this deficiency.<br></blockquote><div><br></div><div><br></div></span><div>Since they are orginally from LinkOnceODR defs, whatever definition is picked up is implementation dependent.</div></div></div></div></blockquote><div><br></div></span><div>Right for the multiply defined ODR refs, it shouldn't matter that the second link picks a different copy (we just need to do the conservative thing as in this and my other patch to ensure we don't introduce backwards refs).</div><div><br></div><div>I do have a worry about non-ODR multiply defined case. E.g. In the example if the first copy originally chosen as prevailing is weak (non-odr), and due to the importing of strong references to that object we no longer linked in its symbols in the second link, we might end up linking with a different weak copy that has a different body - resulting in different program behavior. If that is a real concern then I suppose we must do something else to ensure that the same copy is prevailing in the second link...</div></div></div></div></blockquote><div><br></div><div>In this case, whatever copy (of the weak def) that is picked up is implementation defined -- for instance link line order. Practically speaking, it should not be a concern.</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
><br>
<br>
><br>
<br>
> > If a list of `.o` on the command line is not enough for relinking, there's gonna be a need for a "linker resolution map" file that drives the linker.<br>
<br>
><br>
<br>
><br>
<br>
> In ThinLTO it is because of the change (between the ThinLink and native object link) in which strong references exist between objects/libraries due to importing and inlining. But I believe with this patch and the follow-on <a href="https://reviews.llvm.org/D22467" rel="noreferrer" target="_blank">https://reviews.llvm.org/D22467</a> the importing and symbol resolution is made suitably conservative.<br>
<br>
<br>
</span>I don't see any justification for --start-lib/--end-lib right now.<br>
<br></blockquote><div><br></div></span><div>Can you clarify what do you mean by 'justification' here?</div></div></div></div></blockquote><div><br></div></span><div>Reading through Mehdi's comments, I think he didn't realize we were already using --start-lib/--end-lib instead of regular archive libraries.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>thanks,</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<a href="https://reviews.llvm.org/D22356" rel="noreferrer" target="_blank">https://reviews.llvm.org/D22356</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div><span class="HOEnZb"><font color="#888888">
</font></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div data-smartmail="gmail_signature"><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> <a href="tel:408-460-2413" value="+14084602413" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</font></span></div></div>
</blockquote></div><br></div></div>