llvm dev - Oct 2017 - Should we switch to --hash-style=both by default in LLD ?

Le 2 oct. 2017 à 18:37, Rui Ueyama <ruiu at google.com<mailto:ruiu at
google.com>> a écrit :

Changing default to "both" is probably fine, but what does that change
actually mean in practice? I believe clang already passes --hash-style=both to
the linker by default.

Not exactly.

The current Linux driver (I haven't checked other ELF-based systems) reads
this
(https://github.com/llvm-mirror/clang/blob/master/lib/Driver/ToolChains/Linux.cpp#L228)


  // Do not use 'gnu' hash style for Mips targets because .gnu.hash
  // and the MIPS ABI require .dynsym to be sorted in different ways.
  // .gnu.hash needs symbols to be grouped by hash code whereas the MIPS
  // ABI requires a mapping between the GOT and the symbol table.
  // Android loader does not support .gnu.hash.
  // Hexagon linker/loader does not support .gnu.hash
  if (!IsMips && !IsAndroid && !IsHexagon) {
    if (Distro.IsRedhat() || Distro.IsOpenSUSE() ||
        (Distro.IsUbuntu() && Distro >= Distro::UbuntuMaverick))
      ExtraOpts.push_back("--hash-style=gnu");

    if (Distro.IsDebian() || Distro.IsOpenSUSE() || Distro ==
Distro::UbuntuLucid ||
        Distro == Distro::UbuntuJaunty || Distro == Distro::UbuntuKarmic)
      ExtraOpts.push_back("--hash-style=both");
  }

Given that several libc implementation supports this in the Linux ecosystem
(glibc, musl, uClibc, most likely others) I think lld should provide good
defaults by default, instead of relying on what some distro maintainer have
hardcoded for their own distro in clang.

Cheers,
ROmain
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171002/5989bb0d/attachment-0001.html>

I read through the binutils mailing list thread, but I couldn't find the
exact reason why making --hash-style=gnu default except MIPS wasn't a good
idea.Do you mind if I ask you to explain it again for me?

Since lld is a new linker, we could make a bit more radical change than GNU
ld can do, so I wonder if --hash-style=both is the right choice for us.

On Mon, Oct 2, 2017 at 3:00 PM, Romain GEISSLER <romain.geissler at
amadeus.com
> wrote:
> Le 2 oct. 2017 à 18:37, Rui Ueyama <ruiu at google.com> a écrit :
>
> Changing default to "both" is probably fine, but what does that
change
> actually mean in practice? I believe clang already passes --hash-style=both
> to the linker by default.
>
>
> Not exactly.
>
> The current Linux driver (I haven't checked other ELF-based systems)
reads
> this (https://github.com/llvm-mirror/clang/blob/master/lib/
> Driver/ToolChains/Linux.cpp#L228)
>
>
>   // Do not use 'gnu' hash style for Mips targets because .gnu.hash
>   // and the MIPS ABI require .dynsym to be sorted in different ways.
>   // .gnu.hash needs symbols to be grouped by hash code whereas the MIPS
>   // ABI requires a mapping between the GOT and the symbol table.
>   // Android loader does not support .gnu.hash.
>   // Hexagon linker/loader does not support .gnu.hash
>   if (!IsMips && !IsAndroid && !IsHexagon) {
>     if (Distro.IsRedhat() || Distro.IsOpenSUSE() ||
>         (Distro.IsUbuntu() && Distro >= Distro::UbuntuMaverick))
>       ExtraOpts.push_back("--hash-style=gnu");
>
>     if (Distro.IsDebian() || Distro.IsOpenSUSE() || Distro =>
Distro::UbuntuLucid ||
>         Distro == Distro::UbuntuJaunty || Distro == Distro::UbuntuKarmic)
>       ExtraOpts.push_back("--hash-style=both");
>   }
>
> Given that several libc implementation supports this in the Linux
> ecosystem (glibc, musl, uClibc, most likely others) I think lld should
> provide good defaults by default, instead of relying on what some distro
> maintainer have hardcoded for their own distro in clang.
>
> Cheers,
> ROmain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171002/56623e23/attachment.html>

> Le 3 oct. 2017 à 00:09, Rui Ueyama <ruiu at google.com> a écrit :
> 
> I read through the binutils mailing list thread, but I couldn't find
the exact reason why making --hash-style=gnu default except MIPS wasn't a
good idea.Do you mind if I ask you to explain it again for me?
> 
> Since lld is a new linker, we could make a bit more radical change than GNU
ld can do, so I wonder if --hash-style=both is the right choice for us.
To be honest, I have no idea. I am much more on the user side of ld.bfd/ld.gold
than the developer side. I know very little about the exact specific ELF ABI
Michael Matz is referring to. I actually would expect you lld developers to have
quite an good knowledge of it ;)

On my side, I do configure and/or patch all my linkers (bfd, gold and lld) to
use the "gnu" hash-style by default, and I can only say that with a
classical glibc environment, it works. The fact that some Linux distro are doing
that too seems to be a good arguments that it is safe, at least when using
glibc. The question is more whether lld seeks (size) optimization over
correctness (wrt the ELF specification) ?

Cheers,
Romain