* [Buildroot] [PATCH v2 1/4] package/Makefile.in: use gcc wrappers for binutils tools
@ 2020-10-17 22:17 Norbert Lange
2020-10-17 22:17 ` [Buildroot] [PATCH v2 2/4] package/gcc: use binutils wrappers for target libs Norbert Lange
` (3 more replies)
0 siblings, 4 replies; 13+ messages in thread
From: Norbert Lange @ 2020-10-17 22:17 UTC (permalink / raw)
To: buildroot
This will use gcc-ar, gcc-nm and gcc-ranlib instead of the
normal binutils tools. The difference is that with the
wrappers, gcc plugins will be automatically picked up.
gcc 4.7 introduced these wrappers, to detect the prefix and
keep gcc specifics out of Makefile.in, a new variable
BR2_TOOLCHAIN_BUTILS_PREFIX will be used to carry the
prefix on supported versions.
Note that binutils added some automatic loading with the
'bfd-plugins' directory (somewhere around 2.28), but
the first implementation had issues, and generally depends on
correctly setup symlinks (often broken, may point to some
other gcc's library). The wrappers always work painless.
The original motivation (now ~2 years in use) was to add
"-flto -ffat-lto-objects" to both BR2_TARGET_OPTIMIZATION and
BR2_TARGET_LDFLAGS, and have target binaries lto optimized.
Not all packages will compile with this option, further work
could white/blacklist packages (adding -fno-lto to the
options).
Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
v1->v2:
* support older gcc versions missing those wrappers
---
package/Makefile.in | 6 +++---
toolchain/Config.in | 7 +++++++
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/package/Makefile.in b/package/Makefile.in
index 51f5cbce4f..665edec539 100644
--- a/package/Makefile.in
+++ b/package/Makefile.in
@@ -198,15 +198,15 @@ TARGET_CROSS = $(HOST_DIR)/bin/$(TOOLCHAIN_EXTERNAL_PREFIX)-
endif
# Define TARGET_xx variables for all common binutils/gcc
-TARGET_AR = $(TARGET_CROSS)ar
+TARGET_AR = $(TARGET_CROSS)$(call qstrip,$(BR2_TOOLCHAIN_BUTILS_PREFIX))ar
TARGET_AS = $(TARGET_CROSS)as
TARGET_CC = $(TARGET_CROSS)gcc
TARGET_CPP = $(TARGET_CROSS)cpp
TARGET_CXX = $(TARGET_CROSS)g++
TARGET_FC = $(TARGET_CROSS)gfortran
TARGET_LD = $(TARGET_CROSS)ld
-TARGET_NM = $(TARGET_CROSS)nm
-TARGET_RANLIB = $(TARGET_CROSS)ranlib
+TARGET_NM = $(TARGET_CROSS)$(call qstrip,$(BR2_TOOLCHAIN_BUTILS_PREFIX))nm
+TARGET_RANLIB = $(TARGET_CROSS)$(call qstrip,$(BR2_TOOLCHAIN_BUTILS_PREFIX))ranlib
TARGET_READELF = $(TARGET_CROSS)readelf
TARGET_OBJCOPY = $(TARGET_CROSS)objcopy
TARGET_OBJDUMP = $(TARGET_CROSS)objdump
diff --git a/toolchain/Config.in b/toolchain/Config.in
index db2ab0f059..7a2becc09a 100644
--- a/toolchain/Config.in
+++ b/toolchain/Config.in
@@ -732,4 +732,11 @@ config BR2_TOOLCHAIN_HAS_LIBQUADMATH
bool
default y if BR2_i386 || BR2_x86_64
+# gcc ships with wrappers that will automatically pass arguments
+# to the binutils tools.
+# So far, those are paths to necessary linker plugins
+config BR2_TOOLCHAIN_BUTILS_PREFIX
+ string
+ default "gcc-" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
+
endmenu
--
2.28.0
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [Buildroot] [PATCH v2 2/4] package/gcc: use binutils wrappers for target libs
2020-10-17 22:17 [Buildroot] [PATCH v2 1/4] package/Makefile.in: use gcc wrappers for binutils tools Norbert Lange
@ 2020-10-17 22:17 ` Norbert Lange
2022-01-09 15:16 ` Yann E. MORIN
2020-10-17 22:17 ` [Buildroot] [PATCH v2 3/4] package/busybox: explicitly state binutil paths Norbert Lange
` (2 subsequent siblings)
3 siblings, 1 reply; 13+ messages in thread
From: Norbert Lange @ 2020-10-17 22:17 UTC (permalink / raw)
To: buildroot
This will use gcc-ar, gcc-nm and gcc-ranlib instead of the
normal binutils tools. The difference is that with the
wrappers, gcc plugins will be automatically picked up,
which might be necessary with some flags.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
v1->v2:
* Only set those wrappers if gc 4.7 or newer
---
package/gcc/gcc.mk | 3 +++
1 file changed, 3 insertions(+)
diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
index 114c2887a0..a24ffe3ee2 100644
--- a/package/gcc/gcc.mk
+++ b/package/gcc/gcc.mk
@@ -99,6 +99,9 @@ GCC_COMMON_TARGET_CFLAGS += -Wno-error
endif
# Propagate options used for target software building to GCC target libs
+ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_4_7),y)
+HOST_GCC_COMMON_CONF_ENV += AR_FOR_TARGET=gcc-ar NM_FOR_TARGET=gcc-nm RANLIB_FOR_TARGET=gcc-ranlib
+endif
HOST_GCC_COMMON_CONF_ENV += CFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_CFLAGS)"
HOST_GCC_COMMON_CONF_ENV += CXXFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_CXXFLAGS)"
--
2.28.0
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [Buildroot] [PATCH v2 3/4] package/busybox: explicitly state binutil paths
2020-10-17 22:17 [Buildroot] [PATCH v2 1/4] package/Makefile.in: use gcc wrappers for binutils tools Norbert Lange
2020-10-17 22:17 ` [Buildroot] [PATCH v2 2/4] package/gcc: use binutils wrappers for target libs Norbert Lange
@ 2020-10-17 22:17 ` Norbert Lange
2022-01-09 15:09 ` Yann E. MORIN
2020-10-17 22:17 ` [Buildroot] [PATCH v2 4/4] package/glibc: force -fno-lto Norbert Lange
2022-01-09 15:08 ` [Buildroot] [PATCH v2 1/4] package/Makefile.in: use gcc wrappers for binutils tools Yann E. MORIN
3 siblings, 1 reply; 13+ messages in thread
From: Norbert Lange @ 2020-10-17 22:17 UTC (permalink / raw)
To: buildroot
Pass paths to ar, nm, ranlib binaries. This allows linker-plugins
to be used.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
package/busybox/busybox.mk | 3 +++
1 file changed, 3 insertions(+)
diff --git a/package/busybox/busybox.mk b/package/busybox/busybox.mk
index 01f7331221..221b8adf59 100644
--- a/package/busybox/busybox.mk
+++ b/package/busybox/busybox.mk
@@ -94,6 +94,9 @@ BUSYBOX_MAKE_ENV += \
endif
BUSYBOX_MAKE_OPTS = \
+ AR="$(TARGET_AR)" \
+ NM="$(TARGET_NM)" \
+ RANLIB="$(TARGET_RANLIB)" \
CC="$(TARGET_CC)" \
ARCH=$(KERNEL_ARCH) \
PREFIX="$(TARGET_DIR)" \
--
2.28.0
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [Buildroot] [PATCH v2 4/4] package/glibc: force -fno-lto
2020-10-17 22:17 [Buildroot] [PATCH v2 1/4] package/Makefile.in: use gcc wrappers for binutils tools Norbert Lange
2020-10-17 22:17 ` [Buildroot] [PATCH v2 2/4] package/gcc: use binutils wrappers for target libs Norbert Lange
2020-10-17 22:17 ` [Buildroot] [PATCH v2 3/4] package/busybox: explicitly state binutil paths Norbert Lange
@ 2020-10-17 22:17 ` Norbert Lange
2022-01-09 22:31 ` Yann E. MORIN
2022-01-09 15:08 ` [Buildroot] [PATCH v2 1/4] package/Makefile.in: use gcc wrappers for binutils tools Yann E. MORIN
3 siblings, 1 reply; 13+ messages in thread
From: Norbert Lange @ 2020-10-17 22:17 UTC (permalink / raw)
To: buildroot
glibc requires compilation barriers between files, and will
fail with LTO enabled.
So force LTO off by appending -fno-lto to the flags, but only
if the GCC version is recent enough that an LTO build would
be possible.
Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
package/glibc/glibc.mk | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
index 4721177d83..6d07495edc 100644
--- a/package/glibc/glibc.mk
+++ b/package/glibc/glibc.mk
@@ -67,6 +67,11 @@ ifeq ($(BR2_ENABLE_DEBUG),y)
GLIBC_EXTRA_CFLAGS += -g
endif
+# glibc explicitly requires compile barriers between files
+ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_4_7),y)
+GLIBC_EXTRA_CFLAGS += -fno-lto
+endif
+
# The stubs.h header is not installed by install-headers, but is
# needed for the gcc build. An empty stubs.h will work, as explained
# in http://gcc.gnu.org/ml/gcc/2002-01/msg00900.html. The same trick
--
2.28.0
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [Buildroot] [PATCH v2 1/4] package/Makefile.in: use gcc wrappers for binutils tools
2020-10-17 22:17 [Buildroot] [PATCH v2 1/4] package/Makefile.in: use gcc wrappers for binutils tools Norbert Lange
` (2 preceding siblings ...)
2020-10-17 22:17 ` [Buildroot] [PATCH v2 4/4] package/glibc: force -fno-lto Norbert Lange
@ 2022-01-09 15:08 ` Yann E. MORIN
3 siblings, 0 replies; 13+ messages in thread
From: Yann E. MORIN @ 2022-01-09 15:08 UTC (permalink / raw)
To: Norbert Lange; +Cc: buildroot
Norbert, All,
On 2020-10-18 00:17 +0200, Norbert Lange spake thusly:
> This will use gcc-ar, gcc-nm and gcc-ranlib instead of the
> normal binutils tools. The difference is that with the
> wrappers, gcc plugins will be automatically picked up.
>
> gcc 4.7 introduced these wrappers, to detect the prefix and
> keep gcc specifics out of Makefile.in, a new variable
> BR2_TOOLCHAIN_BUTILS_PREFIX will be used to carry the
> prefix on supported versions.
>
> Note that binutils added some automatic loading with the
> 'bfd-plugins' directory (somewhere around 2.28), but
> the first implementation had issues, and generally depends on
> correctly setup symlinks (often broken, may point to some
> other gcc's library). The wrappers always work painless.
>
> The original motivation (now ~2 years in use) was to add
> "-flto -ffat-lto-objects" to both BR2_TARGET_OPTIMIZATION and
> BR2_TARGET_LDFLAGS, and have target binaries lto optimized.
>
> Not all packages will compile with this option, further work
> could white/blacklist packages (adding -fno-lto to the
> options).
>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
> v1->v2:
> * support older gcc versions missing those wrappers
> ---
> package/Makefile.in | 6 +++---
> toolchain/Config.in | 7 +++++++
> 2 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/package/Makefile.in b/package/Makefile.in
> index 51f5cbce4f..665edec539 100644
> --- a/package/Makefile.in
> +++ b/package/Makefile.in
> @@ -198,15 +198,15 @@ TARGET_CROSS = $(HOST_DIR)/bin/$(TOOLCHAIN_EXTERNAL_PREFIX)-
> endif
>
> # Define TARGET_xx variables for all common binutils/gcc
> -TARGET_AR = $(TARGET_CROSS)ar
> +TARGET_AR = $(TARGET_CROSS)$(call qstrip,$(BR2_TOOLCHAIN_BUTILS_PREFIX))ar
> TARGET_AS = $(TARGET_CROSS)as
> TARGET_CC = $(TARGET_CROSS)gcc
> TARGET_CPP = $(TARGET_CROSS)cpp
> TARGET_CXX = $(TARGET_CROSS)g++
> TARGET_FC = $(TARGET_CROSS)gfortran
> TARGET_LD = $(TARGET_CROSS)ld
> -TARGET_NM = $(TARGET_CROSS)nm
> -TARGET_RANLIB = $(TARGET_CROSS)ranlib
> +TARGET_NM = $(TARGET_CROSS)$(call qstrip,$(BR2_TOOLCHAIN_BUTILS_PREFIX))nm
> +TARGET_RANLIB = $(TARGET_CROSS)$(call qstrip,$(BR2_TOOLCHAIN_BUTILS_PREFIX))ranlib
> TARGET_READELF = $(TARGET_CROSS)readelf
> TARGET_OBJCOPY = $(TARGET_CROSS)objcopy
> TARGET_OBJDUMP = $(TARGET_CROSS)objdump
> diff --git a/toolchain/Config.in b/toolchain/Config.in
> index db2ab0f059..7a2becc09a 100644
> --- a/toolchain/Config.in
> +++ b/toolchain/Config.in
> @@ -732,4 +732,11 @@ config BR2_TOOLCHAIN_HAS_LIBQUADMATH
> bool
> default y if BR2_i386 || BR2_x86_64
>
> +# gcc ships with wrappers that will automatically pass arguments
> +# to the binutils tools.
> +# So far, those are paths to necessary linker plugins
> +config BR2_TOOLCHAIN_BUTILS_PREFIX
> + string
> + default "gcc-" if BR2_TOOLCHAIN_GCC_AT_LEAST_4_7
There was no need for a Kconfig option, so I moved that to the Makefile
side.
Applied to master, thanks.
Regards,
Yann E. MORIN.
> endmenu
> --
> 2.28.0
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Buildroot] [PATCH v2 3/4] package/busybox: explicitly state binutil paths
2020-10-17 22:17 ` [Buildroot] [PATCH v2 3/4] package/busybox: explicitly state binutil paths Norbert Lange
@ 2022-01-09 15:09 ` Yann E. MORIN
0 siblings, 0 replies; 13+ messages in thread
From: Yann E. MORIN @ 2022-01-09 15:09 UTC (permalink / raw)
To: Norbert Lange; +Cc: buildroot
Norbet, All,
On 2020-10-18 00:17 +0200, Norbert Lange spake thusly:
> Pass paths to ar, nm, ranlib binaries. This allows linker-plugins
> to be used.
I have expanded/reworded the commit log to explain why this is needed
specifically for busybox.
Applied to master, thanks.
Regards,
Yann E. MORIN.
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
> package/busybox/busybox.mk | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/package/busybox/busybox.mk b/package/busybox/busybox.mk
> index 01f7331221..221b8adf59 100644
> --- a/package/busybox/busybox.mk
> +++ b/package/busybox/busybox.mk
> @@ -94,6 +94,9 @@ BUSYBOX_MAKE_ENV += \
> endif
>
> BUSYBOX_MAKE_OPTS = \
> + AR="$(TARGET_AR)" \
> + NM="$(TARGET_NM)" \
> + RANLIB="$(TARGET_RANLIB)" \
> CC="$(TARGET_CC)" \
> ARCH=$(KERNEL_ARCH) \
> PREFIX="$(TARGET_DIR)" \
> --
> 2.28.0
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Buildroot] [PATCH v2 2/4] package/gcc: use binutils wrappers for target libs
2020-10-17 22:17 ` [Buildroot] [PATCH v2 2/4] package/gcc: use binutils wrappers for target libs Norbert Lange
@ 2022-01-09 15:16 ` Yann E. MORIN
2022-01-09 21:08 ` Norbert Lange
0 siblings, 1 reply; 13+ messages in thread
From: Yann E. MORIN @ 2022-01-09 15:16 UTC (permalink / raw)
To: Norbert Lange; +Cc: buildroot
Nrobert, All,
On 2020-10-18 00:17 +0200, Norbert Lange spake thusly:
> This will use gcc-ar, gcc-nm and gcc-ranlib instead of the
> normal binutils tools. The difference is that with the
> wrappers, gcc plugins will be automatically picked up,
> which might be necessary with some flags.
>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
> v1->v2:
> * Only set those wrappers if gc 4.7 or newer
> ---
> package/gcc/gcc.mk | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
> index 114c2887a0..a24ffe3ee2 100644
> --- a/package/gcc/gcc.mk
> +++ b/package/gcc/gcc.mk
> @@ -99,6 +99,9 @@ GCC_COMMON_TARGET_CFLAGS += -Wno-error
> endif
>
> # Propagate options used for target software building to GCC target libs
> +ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_4_7),y)
> +HOST_GCC_COMMON_CONF_ENV += AR_FOR_TARGET=gcc-ar NM_FOR_TARGET=gcc-nm RANLIB_FOR_TARGET=gcc-ranlib
So we were a bit skeptical about this one.
First, we believe that only the final gcc should be using those. Indeed,
we do not need much of the initial gcc, except libgcc.a, which anyway
gets overwitten by the final gcc, so we do not care that the libgcc.a is
built with LTO (and thus the gcc wrappers).
Second, gcc initial is only used to build glibc, and as your patch 4
states, glibc must not be built with LTO, we we also do not care that
the initial gcc uses its wrappers to build libgcc.
Third, shouldn't we be using the tupple-prefixed wrappers? Or does it
just happens that gcc will internally add its build directory to PATH so
that it can find the un-prefixed just-built ones?
For that last point, I added gcc-ar, gcc-nm, and gcc-ranlib in my PATH,
that are just simple wrapper scripts that trace their being called, and
then call to the actual gcca-r et al.:
#!/bin/sh
me="${0}"
my_name="${0##*/}"
found=false
for i in $(which -a "${my_name}"); do
if [ "${i}" -ef "${me}" ]; then
found=true
elif ${found}; then
me="${i}"
fi
done
if ! ${found}; then
exit 42
fi
printf "YEM: wrapped %s\n" "${me}"
exec "${me}" "${@}"
Turns out that the 'YEM: wrapped' string occurs nowhere in the build
directory (so it does not end up in config.log or whatever), and it
does not even appear on the stdout/stderr either.
So I am wondering how we can exercise these... Any hint?
Regards,
Yann E. MORIN.
> +endif
> HOST_GCC_COMMON_CONF_ENV += CFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_CFLAGS)"
> HOST_GCC_COMMON_CONF_ENV += CXXFLAGS_FOR_TARGET="$(GCC_COMMON_TARGET_CXXFLAGS)"
>
> --
> 2.28.0
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Buildroot] [PATCH v2 2/4] package/gcc: use binutils wrappers for target libs
2022-01-09 15:16 ` Yann E. MORIN
@ 2022-01-09 21:08 ` Norbert Lange
2022-01-10 10:43 ` Arnout Vandecappelle
0 siblings, 1 reply; 13+ messages in thread
From: Norbert Lange @ 2022-01-09 21:08 UTC (permalink / raw)
To: Yann E. MORIN; +Cc: buildroot
Am So., 9. Jan. 2022 um 16:16 Uhr schrieb Yann E. MORIN
<yann.morin.1998@free.fr>:
>
> Nrobert, All,
>
> On 2020-10-18 00:17 +0200, Norbert Lange spake thusly:
> > This will use gcc-ar, gcc-nm and gcc-ranlib instead of the
> > normal binutils tools. The difference is that with the
> > wrappers, gcc plugins will be automatically picked up,
> > which might be necessary with some flags.
> >
> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
> > ---
> > v1->v2:
> > * Only set those wrappers if gc 4.7 or newer
> > ---
> > package/gcc/gcc.mk | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
> > index 114c2887a0..a24ffe3ee2 100644
> > --- a/package/gcc/gcc.mk
> > +++ b/package/gcc/gcc.mk
> > @@ -99,6 +99,9 @@ GCC_COMMON_TARGET_CFLAGS += -Wno-error
> > endif
> >
> > # Propagate options used for target software building to GCC target libs
> > +ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_4_7),y)
> > +HOST_GCC_COMMON_CONF_ENV += AR_FOR_TARGET=gcc-ar NM_FOR_TARGET=gcc-nm RANLIB_FOR_TARGET=gcc-ranlib
>
> So we were a bit skeptical about this one.
>
> First, we believe that only the final gcc should be using those. Indeed,
> we do not need much of the initial gcc, except libgcc.a, which anyway
> gets overwitten by the final gcc, so we do not care that the libgcc.a is
> built with LTO (and thus the gcc wrappers).
>
> Second, gcc initial is only used to build glibc, and as your patch 4
> states, glibc must not be built with LTO, we we also do not care that
> the initial gcc uses its wrappers to build libgcc.
>
> Third, shouldn't we be using the tupple-prefixed wrappers? Or does it
> just happens that gcc will internally add its build directory to PATH so
> that it can find the un-prefixed just-built ones?
>
> For that last point, I added gcc-ar, gcc-nm, and gcc-ranlib in my PATH,
> that are just simple wrapper scripts that trace their being called, and
> then call to the actual gcca-r et al.:
>
> #!/bin/sh
> me="${0}"
> my_name="${0##*/}"
> found=false
> for i in $(which -a "${my_name}"); do
> if [ "${i}" -ef "${me}" ]; then
> found=true
> elif ${found}; then
> me="${i}"
> fi
> done
> if ! ${found}; then
> exit 42
> fi
> printf "YEM: wrapped %s\n" "${me}"
> exec "${me}" "${@}"
>
> Turns out that the 'YEM: wrapped' string occurs nowhere in the build
> directory (so it does not end up in config.log or whatever), and it
> does not even appear on the stdout/stderr either.
>
> So I am wondering how we can exercise these... Any hint?
Can't tell anymore, I went to crosstool-ng for the compiler some time ago,
so unlike my other patches I dont use them anymore.
From my memory, it affected some of the additional libs gcc builds,
libstdc++, some sanitizers maybe.
there was not absolute paths or tuples as the various stages should
use the wrappers from the previous ones. I believe the final compiler
ignores PATH and uses the stage2-compiler with abs path to build the
included target libraries.
I am just sure it was very deliberately done *this* way.
Norbert
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Buildroot] [PATCH v2 4/4] package/glibc: force -fno-lto
2020-10-17 22:17 ` [Buildroot] [PATCH v2 4/4] package/glibc: force -fno-lto Norbert Lange
@ 2022-01-09 22:31 ` Yann E. MORIN
2022-01-09 23:09 ` Norbert Lange
0 siblings, 1 reply; 13+ messages in thread
From: Yann E. MORIN @ 2022-01-09 22:31 UTC (permalink / raw)
To: Norbert Lange; +Cc: buildroot
Norbert, All,
On 2020-10-18 00:17 +0200, Norbert Lange spake thusly:
> glibc requires compilation barriers between files, and will
> fail with LTO enabled.
> So force LTO off by appending -fno-lto to the flags, but only
> if the GCC version is recent enough that an LTO build would
> be possible.
>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
Applied to master, thanks.
Are the other C libraries (uClibc, musl) also affected by such an issue?
Regards,
Yann E. MORIN.
> ---
> package/glibc/glibc.mk | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk
> index 4721177d83..6d07495edc 100644
> --- a/package/glibc/glibc.mk
> +++ b/package/glibc/glibc.mk
> @@ -67,6 +67,11 @@ ifeq ($(BR2_ENABLE_DEBUG),y)
> GLIBC_EXTRA_CFLAGS += -g
> endif
>
> +# glibc explicitly requires compile barriers between files
> +ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_4_7),y)
> +GLIBC_EXTRA_CFLAGS += -fno-lto
> +endif
> +
> # The stubs.h header is not installed by install-headers, but is
> # needed for the gcc build. An empty stubs.h will work, as explained
> # in http://gcc.gnu.org/ml/gcc/2002-01/msg00900.html. The same trick
> --
> 2.28.0
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Buildroot] [PATCH v2 4/4] package/glibc: force -fno-lto
2022-01-09 22:31 ` Yann E. MORIN
@ 2022-01-09 23:09 ` Norbert Lange
2022-01-10 7:29 ` Arnout Vandecappelle
0 siblings, 1 reply; 13+ messages in thread
From: Norbert Lange @ 2022-01-09 23:09 UTC (permalink / raw)
To: Yann E. MORIN; +Cc: buildroot
[-- Attachment #1.1: Type: text/plain, Size: 890 bytes --]
Yann E. MORIN <yann.morin.1998@free.fr> schrieb am So., 9. Jan. 2022, 23:31:
> Norbert, All,
>
> On 2020-10-18 00:17 +0200, Norbert Lange spake thusly:
> > glibc requires compilation barriers between files, and will
> > fail with LTO enabled.
> > So force LTO off by appending -fno-lto to the flags, but only
> > if the GCC version is recent enough that an LTO build would
> > be possible.
> >
> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
>
> Applied to master, thanks.
>
> Are the other C libraries (uClibc, musl) also affected by such an issue?
>
Likely, and unless they are tested with LTO I would not trust them to not
have weird runtime issues.
Ideally there would be a whitelist for packages doing fine with LTO, for
now I can only vouch for the couple I am using LTOed since years.
Since a few distros now use LTO by default, hopefully things will get
better.
Norbert
[-- Attachment #1.2: Type: text/html, Size: 1543 bytes --]
[-- Attachment #2: Type: text/plain, Size: 150 bytes --]
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Buildroot] [PATCH v2 4/4] package/glibc: force -fno-lto
2022-01-09 23:09 ` Norbert Lange
@ 2022-01-10 7:29 ` Arnout Vandecappelle
0 siblings, 0 replies; 13+ messages in thread
From: Arnout Vandecappelle @ 2022-01-10 7:29 UTC (permalink / raw)
To: Norbert Lange, Yann E. MORIN; +Cc: buildroot
On 10/01/2022 00:09, Norbert Lange wrote:
>
>
> Yann E. MORIN <yann.morin.1998@free.fr <mailto:yann.morin.1998@free.fr>> schrieb
> am So., 9. Jan. 2022, 23:31:
>
> Norbert, All,
>
> On 2020-10-18 00:17 +0200, Norbert Lange spake thusly:
> > glibc requires compilation barriers between files, and will
> > fail with LTO enabled.
> > So force LTO off by appending -fno-lto to the flags, but only
> > if the GCC version is recent enough that an LTO build would
> > be possible.
> >
> > Signed-off-by: Norbert Lange <nolange79@gmail.com
> <mailto:nolange79@gmail.com>>
>
> Applied to master, thanks.
>
> Are the other C libraries (uClibc, musl) also affected by such an issue?
>
>
> Likely, and unless they are tested with LTO I would not trust them to not have
> weird runtime issues.
>
> Ideally there would be a whitelist for packages doing fine with LTO, for now I
> can only vouch for the couple I am using LTOed since years.
Up to now, the idea was that packages that support LTO would check for it
themselves in their configure step and enable it if available.
It would be a good idea though to add a global option to enable LTO, similar
to SSP etc. The first step for that would be to add a hidden symbol that
indicates if the toolchain has LTO, and that gets selected by the toolchains
that have LTO. Then we have to look at each external toolchain to verify if LTO
is available, and add a checker function to validate that it is correct.
Finally, we can randomly turn on the LTO option in the genrandconfig script, and
fix the fallout on abo.
Regards,
Arnout
>
> Since a few distros now use LTO by default, hopefully things will get better.
>
> Norbert
>
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Buildroot] [PATCH v2 2/4] package/gcc: use binutils wrappers for target libs
2022-01-09 21:08 ` Norbert Lange
@ 2022-01-10 10:43 ` Arnout Vandecappelle
2022-01-25 21:13 ` Arnout Vandecappelle
0 siblings, 1 reply; 13+ messages in thread
From: Arnout Vandecappelle @ 2022-01-10 10:43 UTC (permalink / raw)
To: Norbert Lange, Yann E. MORIN; +Cc: buildroot
On 09/01/2022 22:08, Norbert Lange wrote:
> Am So., 9. Jan. 2022 um 16:16 Uhr schrieb Yann E. MORIN
> <yann.morin.1998@free.fr>:
>>
>> Nrobert, All,
>>
>> On 2020-10-18 00:17 +0200, Norbert Lange spake thusly:
>>> This will use gcc-ar, gcc-nm and gcc-ranlib instead of the
>>> normal binutils tools. The difference is that with the
>>> wrappers, gcc plugins will be automatically picked up,
>>> which might be necessary with some flags.
>>>
>>> Signed-off-by: Norbert Lange <nolange79@gmail.com>
>>> ---
>>> v1->v2:
>>> * Only set those wrappers if gc 4.7 or newer
>>> ---
>>> package/gcc/gcc.mk | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
>>> index 114c2887a0..a24ffe3ee2 100644
>>> --- a/package/gcc/gcc.mk
>>> +++ b/package/gcc/gcc.mk
>>> @@ -99,6 +99,9 @@ GCC_COMMON_TARGET_CFLAGS += -Wno-error
>>> endif
>>>
>>> # Propagate options used for target software building to GCC target libs
>>> +ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_4_7),y)
>>> +HOST_GCC_COMMON_CONF_ENV += AR_FOR_TARGET=gcc-ar NM_FOR_TARGET=gcc-nm RANLIB_FOR_TARGET=gcc-ranlib
>>
>> So we were a bit skeptical about this one.
>>
>> First, we believe that only the final gcc should be using those. Indeed,
>> we do not need much of the initial gcc, except libgcc.a, which anyway
>> gets overwitten by the final gcc, so we do not care that the libgcc.a is
>> built with LTO (and thus the gcc wrappers). >>
>> Second, gcc initial is only used to build glibc, and as your patch 4
>> states, glibc must not be built with LTO, we we also do not care that
>> the initial gcc uses its wrappers to build libgcc.
Although I may have been the one to make this obvservation to begin with, I'm
starting to come back on that. Even though indeed it is probably not very useful
to apply the wrappers to gcc-initial, it doesn't hurt either. And by putting it
in _COMMON_CONF_ENV, we make sure that (almost) all of the options are together
in gcc.mk. Note that --enable-lto is also in COMMON_OPTS.
>>
>> Third, shouldn't we be using the tupple-prefixed wrappers? Or does it
>> just happens that gcc will internally add its build directory to PATH so
>> that it can find the un-prefixed just-built ones?
>>
>> For that last point, I added gcc-ar, gcc-nm, and gcc-ranlib in my PATH,
>> that are just simple wrapper scripts that trace their being called, and
>> then call to the actual gcca-r et al.:
>>
>> #!/bin/sh
>> me="${0}"
>> my_name="${0##*/}"
>> found=false
>> for i in $(which -a "${my_name}"); do
>> if [ "${i}" -ef "${me}" ]; then
>> found=true
>> elif ${found}; then
>> me="${i}"
>> fi
>> done
>> if ! ${found}; then
>> exit 42
>> fi
>> printf "YEM: wrapped %s\n" "${me}"
>> exec "${me}" "${@}"
>>
>> Turns out that the 'YEM: wrapped' string occurs nowhere in the build
>> directory (so it does not end up in config.log or whatever), and it
>> does not even appear on the stdout/stderr either.
>>
>> So I am wondering how we can exercise these... Any hint?
>
> Can't tell anymore, I went to crosstool-ng for the compiler some time ago,
> so unlike my other patches I dont use them anymore. >
> From my memory, it affected some of the additional libs gcc builds,
> libstdc++, some sanitizers maybe.
> there was not absolute paths or tuples as the various stages should
> use the wrappers from the previous ones. I believe the final compiler
> ignores PATH and uses the stage2-compiler with abs path to build the
> included target libraries.
That it doesn't look in PATH indeed sounds feasible.
However, what is very surprising is that GCC doesn't automatically use the
plugins when --enable-lto is passed. Before blindly adding some random options,
we want to really understand why it is needed, in case maybe things are already
broken in some other way, and to be able in the future to make changes and
understand if they're OK or not.
That said, I have checked and indeed, without these options it seems to use
plain ar instead of gcc-ar.
So I looked a bit deeper, and found this really old bug about enabling lto for
libgcc [1]. It refers to a bunch of other issues found while doing this.
For me, however, the conclusion is that the patch should be applied, but with
better explanation. That way, you can set BR2_TARGET_OPTIMIZATION to -flto and
get an LTO'ed libgcc/libstdc++/etc. If LTO is not used, it doesn't harm to use
the wrapper.
There's just one little concern though: I think the wrappers aren't even
generated unless LTO is enabled. But that point is moot - since GCC N (where N >
4.9 and < 9), LTO is enabled by default, and we don't pass --disable-lto if LTO
is not enabled. In other words, nowadays the BR2_GCC_ENABLE_LTO symbol is useless.
Regards,
Arnout
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893
>
> I am just sure it was very deliberately done *this* way.
>
> Norbert
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Buildroot] [PATCH v2 2/4] package/gcc: use binutils wrappers for target libs
2022-01-10 10:43 ` Arnout Vandecappelle
@ 2022-01-25 21:13 ` Arnout Vandecappelle
0 siblings, 0 replies; 13+ messages in thread
From: Arnout Vandecappelle @ 2022-01-25 21:13 UTC (permalink / raw)
To: Norbert Lange, Yann E. MORIN; +Cc: buildroot
On 10/01/2022 11:43, Arnout Vandecappelle wrote:
>
>
> On 09/01/2022 22:08, Norbert Lange wrote:
>> Am So., 9. Jan. 2022 um 16:16 Uhr schrieb Yann E. MORIN
>> <yann.morin.1998@free.fr>:
>>>
>>> Nrobert, All,
>>>
>>> On 2020-10-18 00:17 +0200, Norbert Lange spake thusly:
>>>> This will use gcc-ar, gcc-nm and gcc-ranlib instead of the
>>>> normal binutils tools. The difference is that with the
>>>> wrappers, gcc plugins will be automatically picked up,
>>>> which might be necessary with some flags.
>>>>
>>>> Signed-off-by: Norbert Lange <nolange79@gmail.com>
>>>> ---
>>>> v1->v2:
>>>> * Only set those wrappers if gc 4.7 or newer
>>>> ---
>>>> package/gcc/gcc.mk | 3 +++
>>>> 1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/package/gcc/gcc.mk b/package/gcc/gcc.mk
>>>> index 114c2887a0..a24ffe3ee2 100644
>>>> --- a/package/gcc/gcc.mk
>>>> +++ b/package/gcc/gcc.mk
>>>> @@ -99,6 +99,9 @@ GCC_COMMON_TARGET_CFLAGS += -Wno-error
>>>> endif
>>>>
>>>> # Propagate options used for target software building to GCC target libs
>>>> +ifeq ($(BR2_TOOLCHAIN_GCC_AT_LEAST_4_7),y)
This is actually not needed - the lowest GCC version we have for the internal
toolchain is 8.
>>>> +HOST_GCC_COMMON_CONF_ENV += AR_FOR_TARGET=gcc-ar NM_FOR_TARGET=gcc-nm
>>>> RANLIB_FOR_TARGET=gcc-ranlib
>>>
>>> So we were a bit skeptical about this one.
>>>
>>> First, we believe that only the final gcc should be using those. Indeed,
>>> we do not need much of the initial gcc, except libgcc.a, which anyway
>>> gets overwitten by the final gcc, so we do not care that the libgcc.a is
>>> built with LTO (and thus the gcc wrappers). >>
>>> Second, gcc initial is only used to build glibc, and as your patch 4
>>> states, glibc must not be built with LTO, we we also do not care that
>>> the initial gcc uses its wrappers to build libgcc.
>
> Although I may have been the one to make this obvservation to begin with, I'm
> starting to come back on that. Even though indeed it is probably not very
> useful to apply the wrappers to gcc-initial, it doesn't hurt either. And by
> putting it in _COMMON_CONF_ENV, we make sure that (almost) all of the options
> are together in gcc.mk. Note that --enable-lto is also in COMMON_OPTS.
>
>>>
>>> Third, shouldn't we be using the tupple-prefixed wrappers? Or does it
>>> just happens that gcc will internally add its build directory to PATH so
>>> that it can find the un-prefixed just-built ones?
>>>
>>> For that last point, I added gcc-ar, gcc-nm, and gcc-ranlib in my PATH,
>>> that are just simple wrapper scripts that trace their being called, and
>>> then call to the actual gcca-r et al.:
>>>
>>> #!/bin/sh
>>> me="${0}"
>>> my_name="${0##*/}"
>>> found=false
>>> for i in $(which -a "${my_name}"); do
>>> if [ "${i}" -ef "${me}" ]; then
>>> found=true
>>> elif ${found}; then
>>> me="${i}"
>>> fi
>>> done
>>> if ! ${found}; then
>>> exit 42
>>> fi
>>> printf "YEM: wrapped %s\n" "${me}"
>>> exec "${me}" "${@}"
>>>
>>> Turns out that the 'YEM: wrapped' string occurs nowhere in the build
>>> directory (so it does not end up in config.log or whatever), and it
>>> does not even appear on the stdout/stderr either.
>>>
>>> So I am wondering how we can exercise these... Any hint?
>>
>> Can't tell anymore, I went to crosstool-ng for the compiler some time ago,
>> so unlike my other patches I dont use them anymore. >
>> From my memory, it affected some of the additional libs gcc builds,
>> libstdc++, some sanitizers maybe.
>> there was not absolute paths or tuples as the various stages should
>> use the wrappers from the previous ones. I believe the final compiler
>> ignores PATH and uses the stage2-compiler with abs path to build the
>> included target libraries.
>
> That it doesn't look in PATH indeed sounds feasible.
>
> However, what is very surprising is that GCC doesn't automatically use the
> plugins when --enable-lto is passed. Before blindly adding some random
> options, we want to really understand why it is needed, in case maybe things
> are already broken in some other way, and to be able in the future to make
> changes and understand if they're OK or not.
>
> That said, I have checked and indeed, without these options it seems to use
> plain ar instead of gcc-ar.
>
> So I looked a bit deeper, and found this really old bug about enabling lto
> for libgcc [1]. It refers to a bunch of other issues found while doing this.
>
> For me, however, the conclusion is that the patch should be applied, but with
> better explanation. That way, you can set BR2_TARGET_OPTIMIZATION to -flto and
> get an LTO'ed libgcc/libstdc++/etc. If LTO is not used, it doesn't harm to use
> the wrapper.
I summarized this discussion and applied to master, thanks.
Regards,
Arnout
>
> There's just one little concern though: I think the wrappers aren't even
> generated unless LTO is enabled. But that point is moot - since GCC N (where N
> > 4.9 and < 9), LTO is enabled by default, and we don't pass --disable-lto if
> LTO is not enabled. In other words, nowadays the BR2_GCC_ENABLE_LTO symbol is
> useless.
>
>
> Regards,
> Arnout
>
>
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59893
>
>
>
>>
>> I am just sure it was very deliberately done *this* way.
>>
>> Norbert
>> _______________________________________________
>> buildroot mailing list
>> buildroot@buildroot.org
>> https://lists.buildroot.org/mailman/listinfo/buildroot
>>
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2022-01-25 21:13 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-17 22:17 [Buildroot] [PATCH v2 1/4] package/Makefile.in: use gcc wrappers for binutils tools Norbert Lange
2020-10-17 22:17 ` [Buildroot] [PATCH v2 2/4] package/gcc: use binutils wrappers for target libs Norbert Lange
2022-01-09 15:16 ` Yann E. MORIN
2022-01-09 21:08 ` Norbert Lange
2022-01-10 10:43 ` Arnout Vandecappelle
2022-01-25 21:13 ` Arnout Vandecappelle
2020-10-17 22:17 ` [Buildroot] [PATCH v2 3/4] package/busybox: explicitly state binutil paths Norbert Lange
2022-01-09 15:09 ` Yann E. MORIN
2020-10-17 22:17 ` [Buildroot] [PATCH v2 4/4] package/glibc: force -fno-lto Norbert Lange
2022-01-09 22:31 ` Yann E. MORIN
2022-01-09 23:09 ` Norbert Lange
2022-01-10 7:29 ` Arnout Vandecappelle
2022-01-09 15:08 ` [Buildroot] [PATCH v2 1/4] package/Makefile.in: use gcc wrappers for binutils tools Yann E. MORIN
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.