<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jan 18, 2018, at 9:43 PM, Saleem Abdulrasool <<a href="mailto:compnerd@compnerd.org" class="">compnerd@compnerd.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">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.</div></div></blockquote><div><br class=""></div><div>I’ve updated the patch, its pretty much ready to go. I’ve added a new section type, documentation, and some additional tests. Please give it a final look, I’d like to get this in soon.</div><div><br class=""></div><div>Thanks!</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 12, 2018 at 8:41 PM, Rui Ueyama via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><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" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div class="gmail-h5">On Fri, Jan 12, 2018 at 5:56 PM, Cary Coutant via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><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="">> Given how ELF works I would expect an unknown section to simply end up<br class="">
> in the output, but we can use SHF_EXCLUDE to avoid that.<br class="">
<br class="">
</span>Yes, gold currently treats unknown section types pretty much the same<br class="">
as PROGBITS sections. The SHF_ALLOCATE and SHF_EXCLUDE flags would<br class="">
control where and whether the section goes into the output file.<br class="">
<br class="">
Another thing that we need to work out is the link order. The link<br class="">
order is basically a topologically-ordered list of objects, ordered so<br class="">
that if A depends on B, A precedes B in the link order. Today, in the<br class="">
absence of any dependency information at all, we rely on the user and<br class="">
compiler to come up with a reasonably correct link order and pass a<br class="">
linear list of files and libraries to the linker. In an ideal world<br class="">
(e.g., one where you can just type "ld main.o"), we'd have explicit<br class="">
dependencies for every object, and we could construct a topological<br class="">
order automatically. But with this feature, we will have a partial<br class="">
list of explicit dependencies, and without a complete list, we have no<br class="">
good way of adding new objects into the link order.<br class="">
<br class="">
One way to approximate a proper link order would be to place each<br class="">
added object immediately after the last object that requests it. For<br class="">
example, if you run "ld a.o b.o c.o -lc", and both a.o and b.o request<br class="">
libm, you would insert libm (i.e., any and all objects extracted from<br class="">
libm if it's an archive library) after b.o and before c.o. But this<br class="">
approach wouldn't work -- we'd have to read and process the directive<br class="">
section from every object before establishing the final link order,<br class="">
which means we can't start building our symbol table until we've read<br class="">
all the objects, which means we can't search archive libraries.<br class=""></blockquote><div class=""><br class=""></div></div></div><div class="">I'm little confused. Even if the final command line becomes something like this:</div><div class=""><br class=""></div><div class=""> ld -static a.o -lm b.o -lm c.o -lc</div><div class=""><br class=""></div><div class="">it links without any problem, no? I mean no files will be pulled out from libm.a more than once.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></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 class="">
library into the link order immediately after the object that requests<br class="">
it, but only if the object hasn't already been inserted and isn't<br class="">
already listed on the command line (i.e., we won't try to load the<br class="">
same file twice); and to search each requested archive library<br class="">
immediately after each object that requests it (of course, because of<br class="">
how library searching works, we would load a given archive member once<br class="">
at most). With this method, libm would be searched after both a.o and<br class="">
b.o, so we'd load any members needed by a.o before b.o, and any<br class="">
remaining members needed by b.o before c.o.<br class="">
<br class="">
The difference between this and a proper topological ordering would be<br class="">
small, but would have a subtle effect on symbol interposition. I'm<br class="">
willing to require anyone who depends on symbol interposition to<br class="">
control their link order explicitly via the command line.<br class="">
<br class="">
In my ideal world, archive libraries would carry dependency<br class="">
information rather than the individual objects within them. I suspect<br class="">
that's too much to ask.<br class="">
<br class="">
I see no need for shared libraries to carry any dependency information<br class="">
beyond the DT_NEEDED entries they already have.<br class="">
<br class="">
(It would be so much easier to build a self-driving car if we could<br class="">
immediately jump to the point where all cars are self-driving, right?)<br class="">
<br class="">
-cary<br class="">
</span><span class="gmail-"><div class="gmail-m_3567573200794564314HOEnZb"><div class="gmail-m_3567573200794564314h5">______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</div></div></span></blockquote></div><br class=""></div></div>
<br class="">______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
<br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature">Saleem Abdulrasool<br class="">compnerd (at) compnerd (dot) org</div>
</div></div>
</div></blockquote></div><br class=""></body></html>