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