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

[Joerg Sonnenberger via llvm-dev]

On Mon, Oct 02, 2017 at 03:55:01PM -0700, Rui Ueyama via llvm-dev wrote:
> On Mon, Oct 2, 2017 at 3:33 PM, Romain GEISSLER <romain.geissler at amadeus.com
> > wrote:
> 
> >
> > > 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 ;)
> >
> 
> There are old systems that do not support .gnu.hash sections, but among the
> systems lld support, I believe we can enable --hash-style=gnu except MIPS.

We don't support it in NetBSD and I'm still not very impressed by
.gnu.hash...

> > 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) ?
> >
> 
> I believe .hash section is optional, so an executable only with .gnu.hash
> is still valid in terms of the ELF specification even on a system that
> doesn't recognize .gnu.hash.

I'm moderately sure that many dynamic linkers will reject at least
shared libraries without a supported hash.

Joerg