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

Sat Apr 10 12:52:00 GMT 2010

On 04/10/2010 01:24 AM, Ian Lance Taylor wrote:
> TÃ¶rÃ¶k Edwin<edwintorok@gmail.com>  writes:
>
>> I tried to link the Linux kernel with gold.
>> Everything went fine with linking, however after rebooting the kernel
>> wasn't working: it instantly rebooted as soon as I selected it from
>> grub.
>
>> How can I track down what the problem is with gold here?
>> Has anyone encountered a similar issue before (has anyone got a
>> working kernel with gold)?
>
> People have gotten working kernels with gold.  The kernel and gold
> move in and out of working together.  The kernel uses several
> extremely obscure and undocumented linker script features.  As they
> change the linker scripts, the build sometimes stops working.
>
> The usual approach to fixing the bug is to compare the kernel
> generated by GNU ld with the one generated by gold.  The problem is
> invariably one of the output files generated by a linker script.  So
> look at those files.  Look for significant differences in size.

Here you go, looks like gold dropped 1/3 of the kernel:
-rwxr-xr-x 1 edwin edwin 11M Apr 10 15:38 vmlinux.gold
-rwxr-xr-x 1 edwin edwin 17M Apr 10 15:37 vmlinux.bfd

>  Look
> at the section headers and look for differences in alignment.  If that
> doesn't help you may need to figure out what is crashing, but I can't
> help with that.

I found an easier way to test than rebooting the real system:
kvm -kernel arch/x86/boot/bzImage

If I take the linker command used to create vmlinux, and use the usual 
LD linker to create it, then the kernel starts booting in qemu/kvm.
With gold it instantly reboots.

I diffed the readelf output, and attached it (without the actual symbol 
address diffs, those are huge):
Here are some highlights (- is gold/bad, + is bfd/good):
  offset differences:
  [Nr] Name                 Type         Addr             Off      Size 
     ES Flags Lk Inf A
-[ 1] .text                PROGBITS     ffffffff81000000 00001000 
003d1c55  0 AX     0   0 4096
+[ 1] .text                PROGBITS     ffffffff81000000 00200000 
003d1c55  0 AX     0   0 4096

  alignment differences:
  Program Headers:
    Type           Offset   VirtAddr           PhysAddr 
FileSiz  MemSiz   Flg Align
-  LOAD           0x001000 0xffffffff81000000 0x0000000001000000 
0x5f2000 0x5f2000 R E 0x1000
-  LOAD           0x5f3000 0xffffffff81600000 0x0000000001600000 
0x183220 0x183220 RWE 0x1000
-  LOAD           0x777000 0xffffffffff600000 0x0000000001784000 
0x000888 0x000888 R E 0x1000
-  LOAD           0x778000 0x0000000000000000 0x0000000001785000 
0x014628 0x014628 RW  0x1000
-  LOAD           0x78d000 0xffffffff8179a000 0x000000000179a000 
0x071000 0x456d000 RWE 0x1000
-  NOTE           0x3d2c58 0xffffffff813d1c58 0x00000000013d1c58 
0x00003c 0x00003c     0x4
+  LOAD           0x200000 0xffffffff81000000 0x0000000001000000 
0x5ef000 0x5ef000 R E 0x200000
+  LOAD           0x800000 0xffffffff81600000 0x0000000001600000 
0x183220 0x183220 RWE 0x200000
+  LOAD           0xa00000 0xffffffffff600000 0x0000000001784000 
0x000888 0x000888 R E 0x200000
+  LOAD           0xc00000 0x0000000000000000 0x0000000001785000 
0x014628 0x014628 RW  0x200000
+  LOAD           0xd9a000 0xffffffff8179a000 0x000000000179a000 
0x071000 0x456d000 RWE 0x200000
+  NOTE           0x5d1c58 0xffffffff813d1c58 0x00000000013d1c58 
0x000024 0x000024     0x4

Do these ring any bells?

>
>
>> This is the gold version I am using:
>> GNU gold (GNU Binutils for Debian 2.20.1-system.20100303) 1.9
>
> Use mainline instead.  There have been quite a few bug fixes since the
> 2.20 release.  The 2.20 release is fine for most uses, but not for the
> kernel.

Thanks, I tried the latest CVS. It is still rebooting :(

Here is the link command for vmlinux:
ld -m elf_x86_64 --build-id  -o vmlinux -T arch/x86/kernel/vmlinux.lds 
arch/x86/kernel/head_64.o arch/x86/kernel/head64.o 
arch/x86/kernel/head.o arch/x86/kernel/init_task.o  init/built-in.o 
--start-group  usr/built-in.o  arch/x86/built-in.o  kernel/built-in.o 
mm/built-in.o  fs/built-in.o  ipc/built-in.o  security/built-in.o 
crypto/built-in.o  block/built-in.o  lib/lib.a  arch/x86/lib/lib.a 
lib/built-in.o  arch/x86/lib/built-in.o  drivers/built-in.o 
sound/built-in.o  firmware/built-in.o  arch/x86/pci/built-in.o 
arch/x86/power/built-in.o  arch/x86/video/built-in.o  net/built-in.o 
--end-group .tmp_kallsyms2.o

I run that with gold vs system linker to reproduce the bug, then run 
make bzImage to create the vmlinuz out of it.

I have attached the vmlinux.lds script, but I don't know what I should 
be looking at there.
Should I open a bug and attach all these .o files too?

Best regards,
--Edwin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: readelf.diff.gz
Type: application/x-gzip
Size: 2206 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20100410/dbd21881/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vmlinux.lds.gz
Type: application/x-gzip
Size: 8612 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20100410/dbd21881/attachment-0001.bin>