Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel

[John Reiser <jreiser at bitwagon dot com>]

> Not identical, difference starts at byte 230:
> -vmlinux.gold: file format elf64-x86-64
> +vmlinux.bfd: file format elf64-x86-64
   ...
> It appears to be a difference in the address chosen for that global (and
> other globals later on).

Although the placement of globals chosen from a library need not be
identical, it would be comforting to verify that this is the only reason.
Try changing the link command to remove all *.a (extract and specify each
*.o explicitly).  Then there should be no difference.

> ... there is also difference in padding:
> gold uses 00 00 90 90 (add %al, (%rax) nop nop), while BFD uses 90 90 90
> 90 (4 nops).

That is a dispute over interpretation of the linker script:
      } :text=0x9090
The original spec was from the days when 2==sizeof(int), so padding was
a 16-bit value, thus 0x9090 was all that mattered.  Check the spec
for an update regarding width of padding.  In the meantime, try changing
the script to
      } :text=0x90909090
which should remove this source of differences.

> If I read that correctly it means it uses hardware pages with a pagesize
> of 2MB for kernel text.

Yes.

> Since gold aligns only to 0x1000 perhaps the rodata ends up in the same
> hardware page as the .text.
>
> I think these are the relevant align commands from the vmlinux.lds ...

> . = ALIGN((1 << 21));

It is a bug that gold does not propagate that alignment constraint
to the .p_align.

> If the hw pagesize is 2MB, then its not divisible, so its a bug.
> Should I open a bugreport, or are there some patches to gold that I
> could try?

Definitely open a bug report about ". = ALIGN((1 << 21));"

> I think the .note difference is just due to gold embedding its version:
> -Note section [ 2] '.notes' of 60 bytes at offset 0x3d2c58:
> +Note section [ 2] '.notes' of 36 bytes at offset 0x5d1c58:
> Owner Data size Type
> - GNU 8 GNU_GOLD_VERSION
> - Linker version: gold 1.9
> GNU 20 GNU_BUILD_ID
> - Build ID: a865af685f5222cdc17a28ea4e49d58b2185bc05
> + Build ID: 07b53da4e169ad1079080043ad72384fb80d0ea3

Again, it would be comforting to make a test run with GNU_GOLD_VERSION
omitted, to see if the .text becomes identical (except for Build ID)
with ld.

--