<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Thank you for the update!</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Dec 12, 2016 at 9:28 AM, Rafael Avila de Espindola via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For the last week or so I did a push to build the freebsd ports with lld<br>
and see how mature lld was.<br>
<br>
The results were overall very good and identified a few bugs I fixed in<br>
lld and also a few issues in freebsd and other projects. Looking at<br>
these we should be able to get an idea of what differences in behavior<br>
lld users are likely to noticed and what to call out in the<br>
documentation.<br>
<br>
The short summary is that we can link 19828 packages and 179 fail. There were<br>
also 6175 skipped. Some of these packages are interpreters and<br>
compilers, so there is also quite a bit of testing of the linked<br>
programs.<br></blockquote><div><br></div><div>Why were 6175 packages skipped?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am going on vacation tomorrow (will probably still do some code<br>
reviews), but I have uploaded all the logs and the failed build<br>
directories to<br>
<br>
<a href="https://s3.amazonaws.com/freebsd-poudriere/result.tar.xz" rel="noreferrer" target="_blank">https://s3.amazonaws.com/<wbr>freebsd-poudriere/result.tar.<wbr>xz</a><br>
<br>
In case anyone wants to dig into it.<br>
<br>
Some of the problems I found were easy to hack around, but the hack is<br>
not what I think is the correct solution. A commutative patch is<br>
attached. The issues it avoids are<br>
<br>
* While clang passes all the -L the linker needs, it looks like gcc does<br>
not. Adding "/usr/lib" as a hard coded path fixed an error when<br>
bootstraping one of the gcc packages. The package/upstream should be<br>
changed instead. One of the big design decisions of lld is that it is<br>
always a cross linker, so always searching /usr/lib is really just a<br>
hack.<br>
<br>
* Making libtool happy. Unfortunately libtool looks for the string GNU<br>
in --version to decide if a linker supports the same command lines as<br>
bfd ld. It also looks for "supported targets" in --help and checks if<br>
there is some elf in there to decide if shared libraries are<br>
supported. To work around that the patch prints "LLD (not GNU)" in<br>
--version and ": supported targets: elf" in --help. The real fix is to<br>
update libtool. Hopefully its defaults can be changed. I would<br>
expected that any new linker it doesn't know about will support shared<br>
libraries and resemble the bfd command line.<br>
<br>
* Handling broken comdats. The name of a comdat is stored in a symbol<br>
name. Really old versions of the gnu assembler would use a section<br>
symbol and expect the section name to be used instead. The current<br>
assembler in freebsd doesn't have that bug, but there is a bootstrap<br>
package for ada that has some .o files that were assembled with a<br>
broken assembler. The correct fix is just to regenerate them.<br>
<br>
* Ignoring R_X86_64_RELATIVE. Dtrace on freebsd creates object files<br>
with the R_X86_64_RELATIVE relocation in it. The relocation only<br>
really makes sense for a dynamic linker. We have to change dtrace to<br>
use one of the existing .o relocations or as a last resort create a<br>
new one if for some reason it cannot use any of the existing ones<br>
(this would be a psabi change, no a lld only change). For now the<br>
patch just ignores it.<br>
<br>
The other issues I noticed were<br>
<br>
* Mono tries to use a local dynamic relocation against a symbol that can<br>
be preempted (<a href="https://bugzilla.xamarin.com/show_bug.cgi?id=49218" rel="noreferrer" target="_blank">https://bugzilla.xamarin.com/<wbr>show_bug.cgi?id=49218</a>).<br>
<br>
* The seabios package has a build time check to see if the linker is<br>
working. Looks like they over reduced a testcase for a previous bfd<br>
bug. We fail that (pr31335), but link the package if the test is disabled.<br>
<br>
* We are missing some options<br>
<a href="https://llvm.org/bugs/show_bug.cgi?id=31334" rel="noreferrer" target="_blank">https://llvm.org/bugs/show_<wbr>bug.cgi?id=31334</a><br>
<br>
* The postgresql contrib package tries to build what I think is a plugin<br>
and passes a non pic library early in the command line. With bfd that<br>
works because it never looks at that library. It looks like all that<br>
is needed is to remove the -l from the command line.<br>
<br>
* The open al project builds a library with a protected symbol but then<br>
tries to access it as an absolute value from a program. The truly<br>
correct fix is to make sure that something like dllimport works in<br>
clang. The short term fix is to add -fPIE to the build of the program.<br>
<br>
I have also hit non lld specific issues, like<br>
<a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200937" rel="noreferrer" target="_blank">https://bugs.freebsd.org/<wbr>bugzilla/show_bug.cgi?id=<wbr>200937</a> and some<br>
package missing a dependency on makeinfo, so our numbers might not be<br>
that much worse than bfd building the same revision. I had no time to do<br>
a bfd run to compare.<br>
<br>
Thanks a lot to Ed Maste for the help with the various bumps along the<br>
way. LLD is looking really good, and I can't help but start thinking<br>
about how can we make things better once it is the default linker. In<br>
particular, the way dtrace works (editing .o files in place) seems very<br>
unfriendly to build systems and I would love to chat with people at the<br>
next BSDCan on how to make it better :-)<br>
<br>
<br><br>
Cheers,<br>
Rafael<br>
<br>______________________________<wbr>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div>