This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Help needed to track down bug: linking Linux kernel with gold creates unbootable kernel
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
Attachment:
readelf.diff.gz
Description: GNU Zip compressed data
Attachment:
vmlinux.lds.gz
Description: GNU Zip compressed data