<div dir="ltr">For those interested, I've updated the patch on D40849.  It is significantly simpler, emitting the options as pairs of C-style strings in a section named `.linker-options` as the agreement here was.<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 12, 2018 at 8:41 PM, Rui Ueyama via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail-h5">On Fri, Jan 12, 2018 at 5:56 PM, Cary Coutant via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>> Given how ELF works I would expect an unknown section to simply end up<br>
> in the output, but we can use SHF_EXCLUDE to avoid that.<br>
<br>
</span>Yes, gold currently treats unknown section types pretty much the same<br>
as PROGBITS sections. The SHF_ALLOCATE and SHF_EXCLUDE flags would<br>
control where and whether the section goes into the output file.<br>
<br>
Another thing that we need to work out is the link order. The link<br>
order is basically a topologically-ordered list of objects, ordered so<br>
that if A depends on B, A precedes B in the link order. Today, in the<br>
absence of any dependency information at all, we rely on the user and<br>
compiler to come up with a reasonably correct link order and pass a<br>
linear list of files and libraries to the linker. In an ideal world<br>
(e.g., one where you can just type "ld main.o"), we'd have explicit<br>
dependencies for every object, and we could construct a topological<br>
order automatically. But with this feature, we will have a partial<br>
list of explicit dependencies, and without a complete list, we have no<br>
good way of adding new objects into the link order.<br>
<br>
One way to approximate a proper link order would be to place each<br>
added object immediately after the last object that requests it. For<br>
example, if you run "ld a.o b.o c.o -lc", and both a.o and b.o request<br>
libm, you would insert libm (i.e., any and all objects extracted from<br>
libm if it's an archive library) after b.o and before c.o. But this<br>
approach wouldn't work -- we'd have to read and process the directive<br>
section from every object before establishing the final link order,<br>
which means we can't start building our symbol table until we've read<br>
all the objects, which means we can't search archive libraries.<br></blockquote><div><br></div></div></div><div>I'm little confused. Even if the final command line becomes something like this:</div><div><br></div><div>  ld -static a.o -lm b.o -lm c.o -lc</div><div><br></div><div>it links without any problem, no? I mean no files will be pulled out from libm.a more than once.</div><div><br></div><div>FWIW the notion of the link order is very different in lld because our linking order is similar to Windows linkers rather than the traditional Unix linker.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-">
I think what would work is to insert each requested object or shared<br>
library into the link order immediately after the object that requests<br>
it, but only if the object hasn't already been inserted and isn't<br>
already listed on the command line (i.e., we won't try to load the<br>
same file twice); and to search each requested archive library<br>
immediately after each object that requests it (of course, because of<br>
how library searching works, we would load a given archive member once<br>
at most). With this method, libm would be searched after both a.o and<br>
b.o, so we'd load any members needed by a.o before b.o, and any<br>
remaining members needed by b.o before c.o.<br>
<br>
The difference between this and a proper topological ordering would be<br>
small, but would have a subtle effect on symbol interposition. I'm<br>
willing to require anyone who depends on symbol interposition to<br>
control their link order explicitly via the command line.<br>
<br>
In my ideal world, archive libraries would carry dependency<br>
information rather than the individual objects within them. I suspect<br>
that's too much to ask.<br>
<br>
I see no need for shared libraries to carry any dependency information<br>
beyond the DT_NEEDED entries they already have.<br>
<br>
(It would be so much easier to build a self-driving car if we could<br>
immediately jump to the point where all cars are self-driving, right?)<br>
<br>
-cary<br>
</span><span class="gmail-"><div class="gmail-m_3567573200794564314HOEnZb"><div class="gmail-m_3567573200794564314h5">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></span></blockquote></div><br></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>