GNU Binutils 2.33.1 has been released.

[Romain Naour]

Hi,

Sorry for the late reply.

Le 09/12/2019 à 04:39, Alan Modra a écrit :
> 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.

I'm using two different Buildroot's build directories, one to reproduce the
issue and the second one with the patch reverted in Binutils. Indeed I'm using
two different tollchains but build from the same recipe (only the build
directory change). I expected to have the same result for both except for
__start_ro_after_init and build id... good to know.

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

Ok.

> 
>> 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/vmlinux.lds.h 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:
> 
>  *(.rodata.*)
>  .rodata.str1.4
>                 0x000000008c8039a8      0x175 arch/sh/boot/compressed/misc.o
>  .rodata..compressed
>                 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/vmlinux.lds.h~	2019-01-17 07:34:38.000000000 +1030
> +++ ./include/asm-generic/vmlinux.lds.h	2019-12-09 11:36:05.778675948 +1030
> @@ -306,6 +306,7 @@
>   */
>  #ifndef RO_AFTER_INIT_DATA
>  #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 @@
>  SECTIONS
>  {
> -  .rodata..compressed : {
> +  .rodata..compressed : ALIGN(8) {
>  	input_len = .;
>  	LONG(input_data_end - input_data) input_data = .;
>  	*(.data)
> 

Thanks a lot for your time!
I tested your patch and the system boot successfully in Qemu.

I'll remove from Buildroot the patch in Binutils package and add theses two
patches for the sh4 kernel.

Can you send them upstream?
Thanks a lot.

Best regards,
Romain