This is the mail archive of the
mailing list for the binutils project.
Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel
- From: John Reiser <jreiser at bitwagon dot com>
- To: binutils at sourceware dot org
- Date: Mon, 12 Apr 2010 08:17:25 -0700
- Subject: Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel
- References: <4BC213FF.email@example.com> <4BC2EA4E.firstname.lastname@example.org>
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:
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
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.
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
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)