When building x86 with Clang LTO and CFI, CFI jump regions are
automatically added to the end of the .text section late in linking. As a
result, the _etext position was being labelled before the appended jump
regions, causing confusion about where the boundaries of the executable
region actually are in the running kernel, and broke at least the fault
injection code. This moves the _etext mark to outside (and immediately
after) the .text area, as it already the case on other architectures
(e.g. arm64, arm).
Reported-and-tested-by: Sami Tolvanen <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
---
arch/x86/kernel/vmlinux.lds.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index bad8c51fee6e..de94da2366e7 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -141,11 +141,11 @@ SECTIONS
*(.text.__x86.indirect_thunk)
__indirect_thunk_end = .;
#endif
-
- /* End of text section */
- _etext = .;
} :text = 0x9090
+ /* End of text section */
+ _etext = .;
+
NOTES :text :note
EXCEPTION_TABLE(16) :text = 0x9090
--
2.17.1
--
Kees Cook
Commit-ID: 392bef709659abea614abfe53cf228e7a59876a4
Gitweb: https://git.kernel.org/tip/392bef709659abea614abfe53cf228e7a59876a4
Author: Kees Cook <[email protected]>
AuthorDate: Tue, 23 Apr 2019 11:38:27 -0700
Committer: Ingo Molnar <[email protected]>
CommitDate: Wed, 24 Apr 2019 12:27:47 +0200
x86/build: Move _etext to actual end of .text
When building x86 with Clang LTO and CFI, CFI jump regions are
automatically added to the end of the .text section late in linking. As a
result, the _etext position was being labelled before the appended jump
regions, causing confusion about where the boundaries of the executable
region actually are in the running kernel, and broke at least the fault
injection code. This moves the _etext mark to outside (and immediately
after) the .text area, as it already the case on other architectures
(e.g. arm64, arm).
Reported-and-tested-by: Sami Tolvanen <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/20190423183827.GA4012@beast
Signed-off-by: Ingo Molnar <[email protected]>
---
arch/x86/kernel/vmlinux.lds.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index bad8c51fee6e..de94da2366e7 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -141,11 +141,11 @@ SECTIONS
*(.text.__x86.indirect_thunk)
__indirect_thunk_end = .;
#endif
-
- /* End of text section */
- _etext = .;
} :text = 0x9090
+ /* End of text section */
+ _etext = .;
+
NOTES :text :note
EXCEPTION_TABLE(16) :text = 0x9090
On 2019 Apr 23, Kees Cook wrote:
> When building x86 with Clang LTO and CFI, CFI jump regions are
> automatically added to the end of the .text section late in linking. As a
> result, the _etext position was being labelled before the appended jump
> regions, causing confusion about where the boundaries of the executable
> region actually are in the running kernel, and broke at least the fault
> injection code. This moves the _etext mark to outside (and immediately
> after) the .text area, as it already the case on other architectures
> (e.g. arm64, arm).
>
> Reported-and-tested-by: Sami Tolvanen <[email protected]>
> Signed-off-by: Kees Cook <[email protected]>
> ---
> arch/x86/kernel/vmlinux.lds.S | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
> index bad8c51fee6e..de94da2366e7 100644
> --- a/arch/x86/kernel/vmlinux.lds.S
> +++ b/arch/x86/kernel/vmlinux.lds.S
> @@ -141,11 +141,11 @@ SECTIONS
> *(.text.__x86.indirect_thunk)
> __indirect_thunk_end = .;
> #endif
> -
> - /* End of text section */
> - _etext = .;
> } :text = 0x9090
>
> + /* End of text section */
> + _etext = .;
> +
> NOTES :text :note
>
> EXCEPTION_TABLE(16) :text = 0x9090
> --
> 2.17.1
This breaks the build on my system:
RELOCS arch/x86/boot/compressed/vmlinux.relocs
CC arch/x86/boot/compressed/early_serial_console.o
CC arch/x86/boot/compressed/kaslr.o
AS arch/x86/boot/compressed/mem_encrypt.o
CC arch/x86/boot/compressed/kaslr_64.o
Invalid absolute R_X86_64_32S relocation: _etext
make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1
make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs'
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2
make: *** [arch/x86/Makefile:283: bzImage] Error 2
--
Regards,
Johannes
On Tue, May 14, 2019 at 02:04:21PM +0200, Johannes Hirte wrote:
> On 2019 Apr 23, Kees Cook wrote:
> > When building x86 with Clang LTO and CFI, CFI jump regions are
> > automatically added to the end of the .text section late in linking. As a
> > result, the _etext position was being labelled before the appended jump
> > regions, causing confusion about where the boundaries of the executable
> > region actually are in the running kernel, and broke at least the fault
> > injection code. This moves the _etext mark to outside (and immediately
> > after) the .text area, as it already the case on other architectures
> > (e.g. arm64, arm).
> >
> > Reported-and-tested-by: Sami Tolvanen <[email protected]>
> > Signed-off-by: Kees Cook <[email protected]>
> > ---
> > arch/x86/kernel/vmlinux.lds.S | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
> > index bad8c51fee6e..de94da2366e7 100644
> > --- a/arch/x86/kernel/vmlinux.lds.S
> > +++ b/arch/x86/kernel/vmlinux.lds.S
> > @@ -141,11 +141,11 @@ SECTIONS
> > *(.text.__x86.indirect_thunk)
> > __indirect_thunk_end = .;
> > #endif
> > -
> > - /* End of text section */
> > - _etext = .;
> > } :text = 0x9090
> >
> > + /* End of text section */
> > + _etext = .;
> > +
> > NOTES :text :note
> >
> > EXCEPTION_TABLE(16) :text = 0x9090
> > --
> > 2.17.1
>
> This breaks the build on my system:
>
> RELOCS arch/x86/boot/compressed/vmlinux.relocs
> CC arch/x86/boot/compressed/early_serial_console.o
> CC arch/x86/boot/compressed/kaslr.o
> AS arch/x86/boot/compressed/mem_encrypt.o
> CC arch/x86/boot/compressed/kaslr_64.o
> Invalid absolute R_X86_64_32S relocation: _etext
> make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1
> make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs'
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2
> make: *** [arch/x86/Makefile:283: bzImage] Error 2
Interesting! Can you send along your .config and compiler details?
--
Kees Cook
On 2019 Mai 14, Kees Cook wrote:
> On Tue, May 14, 2019 at 02:04:21PM +0200, Johannes Hirte wrote:
> > On 2019 Apr 23, Kees Cook wrote:
> > > When building x86 with Clang LTO and CFI, CFI jump regions are
> > > automatically added to the end of the .text section late in linking. As a
> > > result, the _etext position was being labelled before the appended jump
> > > regions, causing confusion about where the boundaries of the executable
> > > region actually are in the running kernel, and broke at least the fault
> > > injection code. This moves the _etext mark to outside (and immediately
> > > after) the .text area, as it already the case on other architectures
> > > (e.g. arm64, arm).
> > >
> > > Reported-and-tested-by: Sami Tolvanen <[email protected]>
> > > Signed-off-by: Kees Cook <[email protected]>
> > > ---
> > > arch/x86/kernel/vmlinux.lds.S | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
> > > index bad8c51fee6e..de94da2366e7 100644
> > > --- a/arch/x86/kernel/vmlinux.lds.S
> > > +++ b/arch/x86/kernel/vmlinux.lds.S
> > > @@ -141,11 +141,11 @@ SECTIONS
> > > *(.text.__x86.indirect_thunk)
> > > __indirect_thunk_end = .;
> > > #endif
> > > -
> > > - /* End of text section */
> > > - _etext = .;
> > > } :text = 0x9090
> > >
> > > + /* End of text section */
> > > + _etext = .;
> > > +
> > > NOTES :text :note
> > >
> > > EXCEPTION_TABLE(16) :text = 0x9090
> > > --
> > > 2.17.1
> >
> > This breaks the build on my system:
> >
> > RELOCS arch/x86/boot/compressed/vmlinux.relocs
> > CC arch/x86/boot/compressed/early_serial_console.o
> > CC arch/x86/boot/compressed/kaslr.o
> > AS arch/x86/boot/compressed/mem_encrypt.o
> > CC arch/x86/boot/compressed/kaslr_64.o
> > Invalid absolute R_X86_64_32S relocation: _etext
> > make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1
> > make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs'
> > make[2]: *** Waiting for unfinished jobs....
> > make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2
> > make: *** [arch/x86/Makefile:283: bzImage] Error 2
>
> Interesting! Can you send along your .config and compiler details?
Tested with gcc-8.3 and gcc-9.1, both the same result.
Using built-in specs.
COLLECT_GCC=gcc-8.3.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-8.3.0-r1/work/gcc-8.3.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/8.3.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.3.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.3.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/8.3.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/8.3.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 8.3.0-r1 p1.1' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap --enable-vtable-verify --enable-lto --without-isl --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.3.0 (Gentoo 8.3.0-r1 p1.1)
Using built-in specs.
COLLECT_GCC=gcc-9.1.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-9.1.0/work/gcc-9.1.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/9.1.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.1.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.1.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/9.1.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/include/g++-v9 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/9.1.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 9.1.0 p1.0' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-systemtap --enable-vtable-verify --enable-lto --without-isl --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 9.1.0 (Gentoo 9.1.0 p1.0)
--
Regards,
Johannes
On Tue, May 14, 2019 at 06:10:55PM +0200, Johannes Hirte wrote:
> On 2019 Mai 14, Kees Cook wrote:
> > On Tue, May 14, 2019 at 02:04:21PM +0200, Johannes Hirte wrote:
> > > This breaks the build on my system:
> > >
> > > RELOCS arch/x86/boot/compressed/vmlinux.relocs
> > > CC arch/x86/boot/compressed/early_serial_console.o
> > > CC arch/x86/boot/compressed/kaslr.o
> > > AS arch/x86/boot/compressed/mem_encrypt.o
> > > CC arch/x86/boot/compressed/kaslr_64.o
> > > Invalid absolute R_X86_64_32S relocation: _etext
> > > make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1
> > > make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs'
> > > make[2]: *** Waiting for unfinished jobs....
> > > make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2
> > > make: *** [arch/x86/Makefile:283: bzImage] Error 2
> >
> > Interesting! Can you send along your .config and compiler details?
>
> Tested with gcc-8.3 and gcc-9.1, both the same result.
> [...]
> gcc version 8.3.0 (Gentoo 8.3.0-r1 p1.1)
Hm, I'm not able to reproduce this with any of the compilers I have
access to. The most recent I have is:
gcc (Ubuntu 20180425-1ubuntu1) 9.0.0 20180425 (experimental) [trunk revision 259645]
Various stupid questions: did you wipe the whole bulid tree and start
clean? Is this specific to Gentoo's compiler package?
I'll see if I can spin up a Gentoo image...
--
Kees Cook
On 2019 Mai 15, Kees Cook wrote:
> On Tue, May 14, 2019 at 06:10:55PM +0200, Johannes Hirte wrote:
> > On 2019 Mai 14, Kees Cook wrote:
> > > On Tue, May 14, 2019 at 02:04:21PM +0200, Johannes Hirte wrote:
> > > > This breaks the build on my system:
> > > >
> > > > RELOCS arch/x86/boot/compressed/vmlinux.relocs
> > > > CC arch/x86/boot/compressed/early_serial_console.o
> > > > CC arch/x86/boot/compressed/kaslr.o
> > > > AS arch/x86/boot/compressed/mem_encrypt.o
> > > > CC arch/x86/boot/compressed/kaslr_64.o
> > > > Invalid absolute R_X86_64_32S relocation: _etext
> > > > make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1
> > > > make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs'
> > > > make[2]: *** Waiting for unfinished jobs....
> > > > make[1]: *** [arch/x86/boot/Makefile:112: arch/x86/boot/compressed/vmlinux] Error 2
> > > > make: *** [arch/x86/Makefile:283: bzImage] Error 2
> > >
> > > Interesting! Can you send along your .config and compiler details?
> >
> > Tested with gcc-8.3 and gcc-9.1, both the same result.
> > [...]
> > gcc version 8.3.0 (Gentoo 8.3.0-r1 p1.1)
>
> Hm, I'm not able to reproduce this with any of the compilers I have
> access to. The most recent I have is:
>
> gcc (Ubuntu 20180425-1ubuntu1) 9.0.0 20180425 (experimental) [trunk revision 259645]
>
> Various stupid questions: did you wipe the whole bulid tree and start
> clean?
No I didn't. And this fixed it now. After a distclean I'm unable to
reproduce it. So sorry for the noise.
--
Regards,
Johannes
On Thu, May 16, 2019 at 03:56:07PM +0200, Johannes Hirte wrote:
> On 2019 Mai 15, Kees Cook wrote:
> > Various stupid questions: did you wipe the whole bulid tree and start
> > clean?
>
> No I didn't. And this fixed it now. After a distclean I'm unable to
> reproduce it. So sorry for the noise.
Okay, whew! Thanks for double-checking. No worries about the noise:
it wouldn't have been the first time I broke some corner case. :)
--
Kees Cook
Hello,
same problem here.
gcc version 9.1.0 (Gentoo 9.1.0 p1.0)
linux-5.1.6
RELOCS arch/x86/boot/compressed/vmlinux.relocs
Invalid absolute R_X86_64_32S relocation: _etext
make[2]: *** [arch/x86/boot/compressed/Makefile:130: arch/x86/boot/compressed/vmlinux.relocs] Error 1
make[2]: *** Deleting file 'arch/x86/boot/compressed/vmlinux.relocs'
make[2]: *** Waiting for unfinished jobs....
make clean or make distclean did *not* help.
--
Prof. Dr. Klaus Kusche
Private address: Rosenberg 41, 07546 Gera, Germany
+49 365 20413058 [email protected] https://www.computerix.info
Office address: DHGE Gera, Weg der Freundschaft 4, 07546 Gera, Germany
+49 365 4341 306 [email protected] https://www.dhge.de
Hi,
I'm having this problem too, build is failing:
Invalid absolute R_X86_64_32S relocation: _etext
I stayed on the 4.14 branch to help prevent these kind of breakages,
so much for that idea. Gentoo GCC 8.3.0.
Alec
On Wed, Jun 05, 2019 at 11:08:13AM -0500, Alec Ari wrote:
> I'm having this problem too, build is failing:
>
> Invalid absolute R_X86_64_32S relocation: _etext
>
> I stayed on the 4.14 branch to help prevent these kind of breakages,
> so much for that idea. Gentoo GCC 8.3.0.
It seems to be a problem with the Gold linker. Using ld.bfd appears to
work. I haven't narrowed down the problem, unfortunately.
Greg, given that this change was only for special situations (Clang
CFI), can you revert this for the stable trees?
--
Kees Cook
On Wed, Jun 05, 2019 at 11:16:06AM -0700, Kees Cook wrote:
> On Wed, Jun 05, 2019 at 11:08:13AM -0500, Alec Ari wrote:
> > I'm having this problem too, build is failing:
> >
> > Invalid absolute R_X86_64_32S relocation: _etext
> >
> > I stayed on the 4.14 branch to help prevent these kind of breakages,
> > so much for that idea. Gentoo GCC 8.3.0.
>
> It seems to be a problem with the Gold linker. Using ld.bfd appears to
> work. I haven't narrowed down the problem, unfortunately.
>
> Greg, given that this change was only for special situations (Clang
> CFI), can you revert this for the stable trees?
Turns out that Android required it to be reverted too, so no one needs
this :(
I'll go revert this, thanks.
greg k-h
Hello,
Same problem for linux 5.1.7:
Kernel building fails with the same relocation error.
5.1.5 does not have the problem, builds fine for me.
Is there anything I can do to investigate the problem?
--
Prof. Dr. Klaus Kusche
Private address: Rosenberg 41, 07546 Gera, Germany
+49 365 20413058 [email protected] https://www.computerix.info
Office address: DHGE Gera, Weg der Freundschaft 4, 07546 Gera, Germany
+49 365 4341 306 [email protected] https://www.dhge.de
On 2019 Jun 09, Klaus Kusche wrote:
>
> Hello,
>
> Same problem for linux 5.1.7:
> Kernel building fails with the same relocation error.
>
> 5.1.5 does not have the problem, builds fine for me.
>
> Is there anything I can do to investigate the problem?
>
Please try linux 5.1.8. The problematic patch was reverted there.
--
Regards,
Johannes
On Sun, Jun 9, 2019 at 1:00 PM Johannes Hirte
<[email protected]> wrote:
> On 2019 Jun 09, Klaus Kusche wrote:
> > Hello,
> >
> > Same problem for linux 5.1.7:
> > Kernel building fails with the same relocation error.
> >
> > 5.1.5 does not have the problem, builds fine for me.
> >
> > Is there anything I can do to investigate the problem?
> >
>
> Please try linux 5.1.8. The problematic patch was reverted there.
I'm having this same issue with v5.2-rc5 using an older version of gcc
(4.9.2). If I use a more recent version of gcc (7.3.0) it works fine.
Reverting this patch allows gcc v4.9.2 to build kernel v5.2-rc5 successfully.
You said in this chain that you were reverting this patch in stable
kernels. Are you going to revert it in tip-of-tree as well?
- Ross
On Wed, Jun 19, 2019 at 12:37:11PM -0600, Ross Zwisler wrote:
> On Sun, Jun 9, 2019 at 1:00 PM Johannes Hirte
> <[email protected]> wrote:
> > On 2019 Jun 09, Klaus Kusche wrote:
> > > Hello,
> > >
> > > Same problem for linux 5.1.7:
> > > Kernel building fails with the same relocation error.
> > >
> > > 5.1.5 does not have the problem, builds fine for me.
> > >
> > > Is there anything I can do to investigate the problem?
> > >
> >
> > Please try linux 5.1.8. The problematic patch was reverted there.
>
> I'm having this same issue with v5.2-rc5 using an older version of gcc
> (4.9.2). If I use a more recent version of gcc (7.3.0) it works fine.
>
> Reverting this patch allows gcc v4.9.2 to build kernel v5.2-rc5 successfully.
>
> You said in this chain that you were reverting this patch in stable
> kernels. Are you going to revert it in tip-of-tree as well?
My original rationale was that we shouldn't break old toolchains on
old kernels (i.e. if a stable kernel built before it should continue to
bulid). For the latest kernel it was fixing a future problem and
regularizing the linker script (other architectures already do it in
this style), however, it seems to not only be an old gcc issue, but also
a Gold linker issue. Building with LD=ld.gold blows up on a modern gcc
too:
$ gcc --version
gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
...
$ ld.gold --version
GNU gold (GNU Binutils for Ubuntu 2.30) 1.15
...
$ make LD=ld.gold ...
...
Invalid absolute R_X86_64_32S relocation: _etext
Ingo, seems like this should be reverted. What do you think?
--
Kees Cook