lld status on the freebsd ports

[Rafael Avila de Espindola via llvm-commits]

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
documentation.

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
programs.

I am going on vacation tomorrow (will probably still do some code
reviews), but I have uploaded all the logs and the failed build
directories to

https://s3.amazonaws.com/freebsd-poudriere/result.tar.xz

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
  hack.

* 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
  https://llvm.org/bugs/show_bug.cgi?id=31334

* 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...
Name: lld-freebsd-hack.patch
Type: text/x-patch
Size: 4511 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161212/4d669479/attachment.bin>
-------------- next part --------------

Cheers,
Rafael