[PATCH] Fix build error in binutils 2.36

* [PATCH] Fix build error in binutils 2.36
@ 2021-08-02  9:41 Michael Chang
  2021-08-05 13:07 ` Daniel Kiper
  0 siblings, 1 reply; 7+ messages in thread
From: Michael Chang @ 2021-08-02  9:41 UTC (permalink / raw)
  To: The development of GNU GRUB

The xen build fails on binutils 2.36 with the following error.

/usr/lib64/gcc/x86_64-suse-linux/10/../../../../x86_64-suse-linux/bin/ld:
section .note.gnu.property VMA [0000000000400158,0000000000400187]
overlaps section .bss VMA [000000000000f000,000000000041e1af]

The most significant factor is that new assembler (gnu as) generates the
.note.gnu.property section as default. This note section overlaps with
.bss because it doesn't reposition with -Wl,-Ttext,0 with which the base
address of .text section is set, rather the address of
.note.gnu.property is calculated for some reason from 0x400000 where the
elf executable defaults to start.

Using -Ttext-segment doesn't help either, though it is said to set the
address of the first byte of the text segment according to "man ld".
What it actually does is to override the default 0x400000, aka the image
base address, to something else. The entire process can be observed in
the default linker script used by gcc [1]. Therefore we can't expect it
to achieve the same thing as -Ttext given that the first segment where
.text resides is offset by SIZEOF_HEADERS plus some sections may be
preceding it within the first segment.  The end result is .text always
has to start with non-zero address with -Wl,-Ttext-segment,0 if using
default linker script.

As long as grub didn't use ISA information encoded in
.note.gnu.property, we can safely drop it via -Wa,-mx86-used-note=no
assembler option to fix the linker error here.

[1] In /usr/lib64/ldscripts/elf_x86_64.x or use 'gcc -Wl,--verbose ...'
PROVIDE (__executable_start = SEGMENT_START("text-segment", 0x400000));
. = SEGMENT_START("text-segment", 0x400000) + SIZEOF_HEADERS;

Signed-off-by: Michael Chang <mchang@suse.com>
---
 configure.ac | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/configure.ac b/configure.ac
index bee28dbeb..cf0a64378 100644
--- a/configure.ac
+++ b/configure.ac
@@ -836,6 +836,20 @@ if ( test "x$target_cpu" = xi386 || test "x$target_cpu" = xx86_64 ) && test "x$p
   TARGET_CFLAGS="$TARGET_CFLAGS -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-3dnow"
 fi
 
+if ( test "x$target_cpu" = xi386 || test "x$target_cpu" = xx86_64 ); then
+  AC_CACHE_CHECK([whether -Wa,-mx86-used-note works], [grub_cv_cc_mx86_used_note], [
+    CFLAGS="$TARGET_CFLAGS -Wa,-mx86-used-note=no -Werror"
+    AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[]])],
+	[grub_cv_cc_mx86_used_note=yes],
+	[grub_cv_cc_mx86_used_note=no])
+  ])
+
+  if test "x$grub_cv_cc_mx86_used_note" = xyes; then
+    TARGET_CFLAGS="$TARGET_CFLAGS -Wa,-mx86-used-note=no"
+    TARGET_CCASFLAGS="$TARGET_CCASFLAGS -Wa,-mx86-used-note=no"
+  fi
+fi
+
 # GRUB doesn't use float or doubles at all. Yet some toolchains may decide
 # that floats are a good fit to run instead of what's written in the code.
 # Given that floating point unit is disabled (if present to begin with)
-- 
2.31.1



^ permalink raw reply related	[flat|nested] 7+ messages in thread