lld status on the freebsd ports

[Rui Ueyama via llvm-commits]

Thank you for the update!

On Mon, Dec 12, 2016 at 9:28 AM, Rafael Avila de Espindola via llvm-commits
<llvm-commits at lists.llvm.org> wrote:

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

Why were 6175 packages skipped?

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 :-)
>
>
>
> Cheers,
> Rafael
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161212/290d5538/attachment.html>