Skip to contentSkip to conversation

gcc: Support configure option --with-linker-hash-style

PATCH New Stefan Fröberg 6 participants 10 messages Dec 15, 2017 – Nov 10, 2018

lore
Share & tools
lore
#0 lore raw

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

This will set the default hash style that GCC will always use during linking.

---
 package/gcc/Config.in.host | 27 +++++++++++++++++++++++++++
 package/gcc/gcc.mk         | 12 ++++++++++++
 2 files changed, 39 insertions(+)
package/gcc/Config.in.host +27 -0
index 70cce0a5c5..b9391392e1 100644
@@ -152,3 +152,30 @@ config BR2_GCC_ENABLE_GRAPHITE
 
 comment "graphite support needs gcc >= 5.x"
 	depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_5
+
+choice 
+	prompt "Hash style used during linking"
+	default BR2_GCC_HASH_STYLE_GNU
+	help
+	  This tells GCC to pass --hash-style=choice option to the
+	  linker for all final links where choice can be one of
+	  "gnu", "sysv" or "both".
+	  Using "gnu" should give best application startup time.
+
+config BR2_GCC_HASH_STYLE_GNU
+	bool "gnu"
+	help
+	  For new style GNU ".gnu.hash" section.
+
+config BR2_GCC_HASH_STYLE_SYSV
+	bool "sysv"
+	help
+	  For classic ELF ".hash" section.
+
+config BR2_GCC_HASH_STYLE_BOTH
+	bool "both"
+	help
+	  For both the classic ELF ".hash" and
+	  new style GNU ".gnu.hash".
+
+endchoice	  
package/gcc/gcc.mk +12 -0
index 27fc1e987c..51bb22d0e9 100644
@@ -183,6 +183,18 @@ else
 HOST_GCC_COMMON_CONF_OPTS += --without-isl --without-cloog
 endif
 
+ifeq ((BR2_GCC_HASH_STYLE_GNU),y)
+HOST_GCC_COMMON_CONF_OPTS += --with-linker-hash-style=gnu
+endif
+
+ifeq ((BR2_GCC_HASH_STYLE_SYSV),y)
+HOST_GCC_COMMON_CONF_OPTS += --with-linker-hash-style=sysv
+endif
+
+ifeq ((BR2_GCC_HASH_STYLE_BOTH),y)
+HOST_GCC_COMMON_CONF_OPTS += --with-linker-hash-style=both
+endif
+
 ifeq ($(BR2_arc)$(BR2_or1k),y)
 HOST_GCC_COMMON_DEPENDENCIES += host-flex host-bison
 endif
Signature · 1 line
2.13.6
#1 lore raw

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

________________________________________
Van: buildrootNamensStefan Fr?berg
Verzonden: zaterdag 16 december 2017 00:25:30 (UTC+01:00) Amsterdam, Berlijn, Bern, Rome, Stockholm, Wenen
Aan: buildroot at buildroot.org
CC: thomas.petazzoni at free-electrons.com; Stefan Fr?berg
Onderwerp: [Buildroot] [PATCH 1/1] gcc: Support configure option --with-linker-hash-style

This will set the default hash style that GCC will always use during linking.

---
 package/gcc/Config.in.host | 27 +++++++++++++++++++++++++++
 package/gcc/gcc.mk         | 12 ++++++++++++
 2 files changed, 39 insertions(+)
package/gcc/Config.in.host +27 -0
index 70cce0a5c5..b9391392e1 100644
@@ -152,3 +152,30 @@ config BR2_GCC_ENABLE_GRAPHITE
 
 comment "graphite support needs gcc >= 5.x"
        depends on !BR2_TOOLCHAIN_GCC_AT_LEAST_5
+
+choice
+       prompt "Hash style used during linking"
+       default BR2_GCC_HASH_STYLE_GNU
+       help
+         This tells GCC to pass --hash-style=choice option to the
+         linker for all final links where choice can be one of
+         "gnu", "sysv" or "both".
+         Using "gnu" should give best application startup time.
+
+config BR2_GCC_HASH_STYLE_GNU
+       bool "gnu"
+       help
+         For new style GNU ".gnu.hash" section.
+
+config BR2_GCC_HASH_STYLE_SYSV
+       bool "sysv"
+       help
+         For classic ELF ".hash" section.
+
+config BR2_GCC_HASH_STYLE_BOTH
+       bool "both"
+       help
+         For both the classic ELF ".hash" and
+         new style GNU ".gnu.hash".
+
+endchoice
package/gcc/gcc.mk +12 -0
index 27fc1e987c..51bb22d0e9 100644
@@ -183,6 +183,18 @@ else
 HOST_GCC_COMMON_CONF_OPTS += --without-isl --without-cloog
 endif
 
+ifeq ((BR2_GCC_HASH_STYLE_GNU),y)
+HOST_GCC_COMMON_CONF_OPTS += --with-linker-hash-style=gnu
+endif
+
+ifeq ((BR2_GCC_HASH_STYLE_SYSV),y)
+HOST_GCC_COMMON_CONF_OPTS += --with-linker-hash-style=sysv
+endif
+
+ifeq ((BR2_GCC_HASH_STYLE_BOTH),y)
+HOST_GCC_COMMON_CONF_OPTS += --with-linker-hash-style=both
+endif
+
 ifeq ($(BR2_arc)$(BR2_or1k),y)
 HOST_GCC_COMMON_DEPENDENCIES += host-flex host-bison
 endif

--
2.13.6

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

#2 lore raw

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

----- Original Message -----

Quoted 5 lines

From: "Kees van Unen" <[email protected]>
To: buildroot at buildroot.org
Sent: Friday, December 15, 2017 9:27:57 PM
Subject: [Buildroot] FW: [PATCH 1/1] gcc: Support configure option --with-linker-hash-style

Quoted 8 lines

________________________________________
Van: buildrootNamensStefan Fr?berg
Verzonden: zaterdag 16 december 2017 00:25:30 (UTC+01:00) Amsterdam, Berlijn, Bern, Rome, Stockholm, Wenen
Aan: buildroot at buildroot.org
CC: thomas.petazzoni at free-electrons.com; Stefan Fr?berg
Onderwerp: [Buildroot] [PATCH 1/1] gcc: Support configure option --with-linker-hash-style

[...]

Why the hell are these messages being sent to the list?

Isn't it possible to block them?

Signature · 4 lines
Carlos Santos (Casantos) - DATACOM, P&D
?The greatest triumph that modern PR can offer is the transcendent 
success of having your words and actions judged by your reputation, 
rather than the other way about.? ? Christopher Hitchens
#3 lore raw

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

________________________________________
Van: buildrootNamensCarlos Santos
Verzonden: zaterdag 16 december 2017 02:50:36 (UTC+01:00) Amsterdam, Berlijn, Bern, Rome, Stockholm, Wenen
Aan: buildroot at buildroot.org
Onderwerp: Re: [Buildroot] FW: [PATCH 1/1] gcc: Support configure option --with-linker-hash-style

----- Original Message -----

Quoted 5 lines

From: "Kees van Unen" <[email protected]>
To: buildroot at buildroot.org
Sent: Friday, December 15, 2017 9:27:57 PM
Subject: [Buildroot] FW: [PATCH 1/1] gcc: Support configure option --with-linker-hash-style

Quoted 8 lines

________________________________________
Van: buildrootNamensStefan Fr?berg
Verzonden: zaterdag 16 december 2017 00:25:30 (UTC+01:00) Amsterdam, Berlijn, Bern, Rome, Stockholm, Wenen
Aan: buildroot at buildroot.org
CC: thomas.petazzoni at free-electrons.com; Stefan Fr?berg
Onderwerp: [Buildroot] [PATCH 1/1] gcc: Support configure option --with-linker-hash-style

[...]

Why the hell are these messages being sent to the list?

Isn't it possible to block them?

--
Carlos Santos (Casantos) - DATACOM, P&D
?The greatest triumph that modern PR can offer is the transcendent success of having your words and actions judged by your reputation, rather than the other way about.? ? Christopher Hitchens
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

#4 lore raw

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

In reply to Carlos Santos

Hello,

Quoted 3 lines · Carlos Santos

Why the hell are these messages being sent to the list?

Isn't it possible to block them?

I've removed this person from the list of subscribers. Unless he resubscribes, that should be enough to stop the messages.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#5 lore raw

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

In reply to Stefan Fröberg

Hello,

Quoted 4 lines · Stefan Fr?berg

This will set the default hash style that GCC will always use during linking.

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

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
#6 lore raw

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

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:

Quoted 17 lines

Hello,

Quoted 4 lines · Stefan Fr?berg

This will set the default hash style that GCC will always use during linking.

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

#7 lore raw

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

Hi Thomas,

I'm looking at this oldest patch in the patchwork...

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.

If --hash-style option is supported by the compiler, 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.

So, I'm not sure we want to enable only gnu style for all binaries on the target (especially the libc). 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.

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?:

Quoted 39 lines

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:

Quoted 11 lines

Hello,

Quoted 4 lines · Stefan Fr?berg

This will set the default hash style that GCC will always use during linking.

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?

Quoted 6 lines

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

#8 lore raw

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

Quoted 3 lines · Romain Naour

Hi Thomas,

I'm looking at this oldest patch in the patchwork...

Great!

Quoted 10 lines

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

Quoted 4 lines

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

Quoted 1 line

If --hash-style option is supported by the compiler,

... which it is for all gcc versions we support...

Quoted 3 lines

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?

Quoted 2 lines

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?

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?

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.

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.

Quoted 5 lines

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

Regards,
Arnout

Quoted 59 lines

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?:

Quoted 30 lines

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:

Quoted 14 lines

Hello,

Quoted 4 lines · Stefan Fr?berg

This will set the default hash style that GCC will always use during linking.

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.

Quoted 9 lines
Quoted 3 lines

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

#9 lore raw

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

Hi Arnout,

Le 09/11/2018 ? 22:35, Arnout Vandecappelle a ?crit?:

Quoted 19 lines · Romain Naour
Quoted 3 lines

Hi Thomas,

I'm looking at this oldest patch in the patchwork...

Great!

Quoted 10 lines

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

Quoted 7 lines
Quoted 4 lines

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.

Quoted 6 lines
Quoted 3 lines

If --hash-style option is supported by the compiler,

... which it is for all gcc versions we support...

Quoted 8 lines
Quoted 3 lines

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

Quoted 7 lines
Quoted 4 lines

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.

Quoted 8 lines

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.

Quoted 4 lines

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

Quoted 3 lines

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

Quoted 9 lines
Quoted 7 lines

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 :-)

:)

Quoted 8 lines

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

Quoted 70 lines

Regards,
Arnout

Quoted 54 lines

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?:

Quoted 30 lines

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:

Quoted 14 lines

Hello,

Quoted 4 lines · Stefan Fr?berg

This will set the default hash style that GCC will always use during linking.

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.

Quoted 9 lines
Quoted 3 lines

Thanks!

Thomas

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Quoted 5 lines

_______________________________________________
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