This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
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/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)
--
Alan Modra
Australia Development Lab, IBM