[llvm-dev] Linking Linux kernel with LLD

[Sean Silva via llvm-dev]

On Thu, Feb 9, 2017 at 1:27 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> >That address seems to come from >here: https://github.com/
> torvalds/linux/blob/5924bbecd0267d87c24110cbe2041b
> 5075173a25/arch/x86/boot/pm.c#L124
> >
> >```
> >protected_mode_jump(boot_params.hdr.code32_start,
> >   (u32)&boot_params + (ds() << 4));
> >```
> >
> >That boot_params.hdr.code32_start field is probably either invalid (bad
> reloc or something else causing the bootloader to >calculate the wrong
> address) or valid but the thing it thinks it is pointing to wasn't loaded
> (missing PT_LOAD etc.).
>
> boot_params.hdr.code32_start field is valid :) It is 0x100000, like
> expected
>

Then I suspect that that segment isn't being loaded. Is there a PT_LOAD
that covers that address? Is the bootloader loading it?


> (btw thanks for those links on info how kernel boots, they were pretty
> useful).
>

I'm glad you found it useful! Those articles are amazing.


> I checked it is valid using trace:
>
> void go_to_protected_mode(void)
> {
> if (boot_params.hdr.code32_start == 0x100000)
>   puts("go_to_protected_mode 1\n");
> else
>   puts("go_to_protected_mode 2\n");
> while (1) {};
>
> I had to use infinite loop here, because QEMU does not crash for me, but
> do domething what looks like reboot and clears all my traces output.
> Infinite loop helps to see traces text, if placed before dead point.
>
> >
> >Btw, how did you narrow it down to that specific instruction? That's
> pretty handy.
>
> I used very simple approach, did not know how to do that properly :), so inserted
> infinite loops in asm code:
> foo:
>  jmp foo
>
>

I suspected something like this :) I've had to do that in the past. btw if
you are ever in a tight spot, a good thing to remember is EB FE (jmp -2)
which encodes an infinite loop on x86 (all modes, even 16bit I believe). It
is small so can easily be patched over most instruction using a hex editor
if necessary.

-- Sean Silva




> And watched for behavior of QEMU. If it just hanged that was fine, I knew
> I am inside my loop, if QEMU rebooted, I knew it crashed at point I was
> looking for. So tracing bfd linked kernel and using documentation I found
> that startup_64 ​is next destination POI, and found that this instruction
> is the last before QEMU reboots for me.
>
> >I think you can also get DSO with -pie I think, but I don't see that
> either. This is quite mysterious. I also did a quick look at the >linker
> script and didn't see anything at first glance that would cause DSO output
> (can linker scripts even control EType?). The >bootloader might not even
> look at the EType though.
> >
> >-- Sean Silva
>
> I think best way would be to look at what is invocation for BFD here. I am
> pretty sure -shared/-pie flag is just lost because of some configuration
> issue, probably it checks that we are running bfd may be. Just a guess.
>
> George.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170209/38445e98/attachment.html>