[llvm-dev] Linking Linux kernel with LLD

[George Rimar via llvm-dev]

I found that bug finally :)


I dumped output for kernel and observed that LLD output starts from ELF header, while BFD points to some code data it seems, what is expected since execution flow makes jmp there.


That means decompressed kernel was not copied properly and issue is at one of points you sent earlier:

https://github.com/torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b5075173a25/arch/x86/boot/compressed/misc.c#L300


Looking on readelf output for vmlinux,  BFD loads has correct LMAs:

  LOAD           0x0000000000200000 0xffffffff81000000 0x0000000001000000
                 0x0000000000241000 0x0000000000241000  R E    200000
  LOAD           0x0000000000600000 0xffffffff81400000 0x0000000001400000
                 0x0000000000041000 0x0000000000041000  RW     200000
  LOAD           0x0000000000641000 0xffffffff81441000 0x0000000001441000
                 0x0000000000070699 0x00000000000c4000  RWE    200000

But LLD output is broken at that part, all LMA are 0x0000000080000000 here?:
  LOAD           0x0000000000001000 0xffffffff81000000 0x0000000080000000
                 0x0000000000242000 0x0000000000242000  R E    1000
  LOAD           0x0000000000243000 0xffffffff81400000 0x0000000080000000
                 0x0000000000041000 0x0000000000041000  RW     1000
  LOAD           0x0000000000284000 0xffffffff81441000 0x0000000080000000
                 0x0000000000071000 0x00000000000c4000  RWE    1000

That happened because script sets address in next way:
.text : AT(ADDR(.text) - 0xffffffff80000000) { ... }
.data : AT(ADDR(.data) - 0xffffffff80000000) { .. }
.init.begin : AT(ADDR(.init.begin) - 0xffffffff80000000) { ... }

We currently just calculate ADDR(..) as zero in such cases and because of that
always have result == 0x0000000080000000 finally. That is the reason of kernel corruption.

I prepared patch that fixes it: https://reviews.llvm.org/D30163, with that in, I was able to pass that place
and QEMU no more reboots for me !

Though it still hangs a bit later, atm it shows:
CPU: AMD QEMU Virtual CPU version 2.5+ (family: 0x6, model: 0x6, stepping: 0x3)
Performance Events: PMU not available due to virtualization, using software events only.
..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...
..... (found apic 0 pin 2) ...
....... failed.
...trying to set up timer as Virtual Wire IRQ...
..... failed.
...trying to set up timer as ExtINT IRQ...
..... failed :(.
Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug and send a report.  Then try booting with the 'noapic' option.
---[ end Kernel panic - not syncing: IO-APIC + timer doesn't work!  Boot with apic=debug and send a report.  Then try booting with the 'noapic' option.
random: fast init done

but that is definetely a different new issue, I am investigating it.
(at least I am happy there is no more silent QEMU reboots and it shows some readable error messages it seems).


George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170220/2c967f81/attachment.html>