[Buildroot] [PATCH 1/1] gcc: Support configure option --with-linker-hash-style

Sat Nov 10 11:30:23 UTC 2018

Hi Arnout,

Le 09/11/2018 à 22:35, Arnout Vandecappelle a écrit :
> 
> 
> On 09/11/2018 00:49, Romain Naour wrote:
>> Hi Thomas,
>>
>> I'm looking at this oldest patch in the patchwork...
> 
>  Great!
> 
>>
>> So, at the moment we use both hash (sysv and gnu) by default for toolchains with
>> binutils >= 2.30, except for mips architecure which still use sysv hash.
>>
>> See [1]:
>>   # Enable gnu hash only on GNU targets, but not mips
>>   mips*-*-*) enable_default_hash_style=sysv ;;
>>   *-*-gnu* | *-*-linux* | *-*-nacl*) enable_default_hash_style=both ;;
>>   *) enable_default_hash_style=sysv ;;
>>
>> gnu hash style was introduced by [2] (binutils 2.18)
>>
>> The gnu hash style is enabled by default since binutils 2.30 [3] along with sysv
>> hash style.
> 
>  To be exact: since 2.30, binutils has an option for the default hash style, and
> that default is "both" (except for mips), while before the default was "sysv".

Indeed.

> 
> 
>> If --hash-style option is supported by the compiler, 
> 
>  ... which it is for all gcc versions we support...
> 
>> glibc use both hash (sysv
>> and gnu) [4]. But this doesn't mean that all binaries will be build with gnu
>> style hash if binutils < 2.30.
> 
>  ... or if it is mips.
> 
>  However, if GCC is configured with --with-linker-hash-style=foo, then all
> binaries *will* actually be built with that hash style, no?

I'm not sure if gcc's "--with-linker-hash-style=foo" (added in 4.7.0 [1]) win
against "-Wl,--hash-style=bar" added by glibc. (This also mean
--with-linker-hash-style needs gcc >= 4.7.0).

"Prepend --hash-style=LINKER_HASH_STYLE to whatever link_spec we had before."

We should have : "--hash-style=foo --hash-style=bar" on the linker command line.

("bar" should be used in this case I believe)

[1]
https://github.com/gcc-mirror/gcc/commit/3cb9bbfa927aa187048534f9069202c017a78e38

> 
> 
>> So, I'm not sure we want to enable only gnu style for all binaries on the target
>> (especially the libc). 
> 
>  But if I understand correctly, glibc overrides it anyway and always sets
> "both"? So for glibc, at least, there shouldn't be a problem?

This must be verified.

> 
> 
>  As far as I understand, there shouldn't be a problem because all libraries and
> executables *will* be built with the same hash style. There may be three
> problems though:
> 
> 1. If binutils defaults to "sysv" for mips, perhaps the GNU hash style is broken
> there? So perhaps we should disable the option for mips?

Well, we don't have any explanation in the commit log adding the
--enable-default-hash-style option about mips. We don't know why we need to use
sysv on mips.

> 
> 2. Some packages may (actually do) override the default hash style. So if you
> select hash style sysv in gcc, and use a libc which doesn't override it, and
> then try to link a program that itself overrides to hash style gnu, it will fail.

Indeed. IIUC it should be a runtime problem with the dynamic loader.
I haven't tested this patch so far...

> 
> 3. Similar for binary packages: we don't build them, so we don't control the
> hash style. Probably, though, binary packages will use hash style both.

Maybe we have to check each binary package (ex opengl Mali).

> 
> 
>> Binaries that contains only gnu hash style are
>> incompatible with binaries that contains only sysv hash style.
>>
>> The default for the choice should be BR2_GCC_HASH_STYLE_BOTH instead of
>> BR2_GCC_HASH_STYLE_GNU if we want to make this option configurable.
> 
>  Or we could just bite the bullet and see how it goes wrong :-)

:)

> 
>  It makes some kind of sense to make it configurable for now, so that there is a
> way out if there are a few packages that fail with the wrong hash style. But
> then at least we should randomize the options in the autobuilders. The good
> thing is that any problems will be immediately visible at link time (I think at
> least that that's the case; I hope it's not at dynamic load time that the
> problem occurs... And of course, dlopen()'ed libraries will only have runtime
> problems.)

Actually, it's not clear to me about the need of using hash sysv only or gnu
only, why using both hash is not sufficient?

Best regards,
Romain

> 
> 
>  Regards,
>  Arnout
> 
> 
>>
>> Best regards,
>> Romain
>>
>> [1]
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=ld/configure;h=e46248cd089e71323ed20bc33ab0efdde526a2bc;hb=refs/heads/binutils-2_31-branch#l15884
>> [2]
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=fdc90cb46b0f96dd4444ec3d126c87de75fb6e6b
>> [3]
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2760f24c4942853eac7b921e4b8843d57a602654
>> [4]
>> https://sourceware.org/git/?p=glibc.git;a=commit;h=871b91589bf4f6dfe19d5987b0a05bd7cf936ecc
>>
>> Le 17/12/2017 à 15:30, Stefan Fröberg a écrit :
>>> Hi Thomas
>>>
>>> Well, I was just worried that if setting the linking hash style to stone
>>> (aka "gnu") then could
>>> it maybe break builds in some other archs than x86, x86_64 and ARM ?
>>>
>>> So I played carefull and made it configurable by choice.
>>>
>>> Im not sure but I think that option has been hiding in GCC since 4.x and
>>> buildroot lowest is 4.9.
>>> So if it's okay I can cook another patch where it just set's it in stone
>>> without choice ?
>>>
>>> -S-
>>>
>>> Thomas Petazzoni kirjoitti 16.12.2017 klo 17:23:
>>>> Hello,
>>>>
>>>> On Sat, 16 Dec 2017 01:25:30 +0200, Stefan Fröberg wrote:
>>>>> This will set the default hash style that GCC will 
>>>>> always use during linking.
>>>>>
>>>>> Signed-off-by: Stefan Fröberg <stefan.froberg at petroprogram.com>
>>>> Could you explain the motivation for configuring the default hash
>>>> style? If "gnu" gives the best application startup time, why would we
>>>> use a different one?
>>>>
>>>> Generally, the commit log lacks a bit of background, i.e the "why" we
>>>> would want such a change.
>>>>
>>>> Thanks!
>>>>
>>>> Thomas
>>>
>>> _______________________________________________
>>> buildroot mailing list
>>> buildroot at busybox.net
>>> http://lists.busybox.net/mailman/listinfo/buildroot
>>>
>>
>> _______________________________________________
>> buildroot mailing list
>> buildroot at busybox.net
>> http://lists.busybox.net/mailman/listinfo/buildroot
>>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 