This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GNU Binutils 2.33.1 has been released.

On Sun, Dec 08, 2019 at 06:12:45PM +0100, Romain Naour wrote:
> Yes, but I can't explain the difference.
> Here is the diff between the output of readelf on two vmlinux (the result is
> slightly different, only sections comment, symtab, strtab and shstrtab are changed).

Whereas in my case, readelf shows just __start_ro_after_init and build
id differing.  The .comment section changing might indicate you are
using different gccs to compile the two vmlinux binaries.

> Check if binutils 2.33.1 has been used to build the toolchain.

Yes, it really was binutils-2.33.1.  After I hacked things around to
get binutils-2.33.1 to build and the first kernel built, I copied
output/build/linux-4.19.16 to somewhere else, ran "make clean" and
removed some .stamp files in order to get the buildroot make to
rebuild the kernel.  I went into the binutils dir, reverted the patch
you identified, ran make and copied ld/ld-new to
output/host/bin/sh4-buildroot-linux-uclibc-ld (and ld.bfd).  Then ran
make at the buildroot top level again to recompile the kernel using
the new ld.  Why did I do things like that?  Because I like to control
exactly what differs between two builds.

> Have you tried to run the system using Qemu and the command line provided
> previously?

Not until now.  I verified that kernels built with binutils-2.33.1
with either the include/arch/ fix or the mm/kmemleak.c
fix fail.

Digging into that, I copied the good linux-4.19.16/vmlinux and built a
zImage from it.  That failed.  So there was another kernel bug.  I see
this in an arch/sh/boot/compressed/vmlinux linker map file:

                0x000000008c8039a8      0x175 arch/sh/boot/compressed/misc.o
                0x000000008c803b1d   0x2c4bd5 arch/sh/boot/compressed/piggy.o
                0x000000008c803b1d                input_len
                0x000000008c803b21                _binary_arch_sh_boot_compressed_vmlinux_bin_gz_start
                0x000000008c803b21                input_data
                0x000000008cac86ee                output_len
                0x000000008cac86f2                input_data_end
                0x000000008cac86f2                _binary_arch_sh_boot_compressed_vmlinux_bin_gz_end
                0x000000008cac86f4                . = ALIGN (0x4)

So we have the compressed image sitting at an odd address.  It looks
like the sh uncompressor can't handle that.

Here's the fix then to cure these kernel bugs:

--- ./include/asm-generic/	2019-01-17 07:34:38.000000000 +1030
+++ ./include/asm-generic/	2019-12-09 11:36:05.778675948 +1030
@@ -306,6 +306,7 @@
 #define RO_AFTER_INIT_DATA						\
+	. = ALIGN(8);							\
 	__start_ro_after_init = .;					\
 	*(.data..ro_after_init)						\
 	__end_ro_after_init = .;

--- arch/sh/boot/compressed/vmlinux.scr~	2019-01-17 07:34:38.000000000 +1030
+++ arch/sh/boot/compressed/vmlinux.scr	2019-12-09 13:31:03.533135945 +1030
@@ -1,6 +1,6 @@
-  .rodata..compressed : {
+  .rodata..compressed : ALIGN(8) {
 	input_len = .;
 	LONG(input_data_end - input_data) input_data = .;

Alan Modra
Australia Development Lab, IBM

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]