[llvm-dev] Should we switch to --hash-style=both by default in LLD ?
Rui Ueyama via llvm-dev
llvm-dev at lists.llvm.org
Mon Oct 2 16:22:23 PDT 2017
On Mon, Oct 2, 2017 at 4:15 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:
> I don't think there is much value in being different from the gnu
> linkers in here since the common case is to have the compiler driver
> pass an explicit option.
>
> So +1 to changing the default to "both".
>
... except for MIPS, as the way how we need to sort .gnu.hash section
contents is not compatible with a MIPS ABI requirement.
Cheers,
> Rafael
>
> George Rimar <grimar at accesssoftek.com> writes:
>
> > Hi !
> >
> > During linking LLD and other linkers builds a static hash table for
> dynamic symbols,
> > so that in runtime dynamic linker can use this table and find symbols
> faster.
> >
> > --hash-style=style linker option is used to select the hash type:
> > "Set the type of linker's hash table(s). style can be either "sysv" for
> classic ELF ".hash" section,
> > "gnu" for new style GNU ".gnu.hash" section or "both" for both the
> classic ELF ".hash" and new
> > style GNU ".gnu.hash" hash tables. The default is "sysv"."
> >
> > GNU_HASH format is a better version of hash table (
> https://sourceware.org/ml/binutils/2006-10/msg00377.html).
> >
> > We have --hash-style=sysv currently set by default in LLD.
> > Though recently (see https://bugs.llvm.org//show_bug.cgi?id=34712) GNU
> linkers switched to use
> > ".gnu.hash" section format in addition to normally used classic ".hash".
> > So they defaults --hash-style to "both" and this looks to be released
> with binutils 2.30.
> >
> > I think we can switch LLD either to "both" or probably to "gnu" by
> default as well.
> > Initial version of patch that changes default to "both" is here: D38407
> >
> > Any thoughts ?
> >
> > Best regards,
> > George | Developer | Access Softek, Inc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171002/2d29cf2f/attachment.html>
More information about the llvm-dev
mailing list