[llvm-dev] Linking Linux kernel with LLD

[George Rimar via llvm-dev]

Thanks for your ideas, Sean !


>The bug is not likely to be corrupted data in the decompressed output (that is just calling into a gzip routine or something). You shouldn't have to dump/printf->trace from memory during boot to see that data since the "real" kernel binary that is being decompressed into that memory region is probably already somewhere > in your build tree (arch/x86/boot/compressed/Makefile seems like it has the details;

Yeah, what I mean, it not just decompresses it, it also applies relocations to the decompressed output:
__decompress(input_data, input_len, NULL, NULL, output, output_len, NULL, error);
parse_elf(output);
handle_relocations(output, output_len, virt_addr);

My idea of quick dumping was based on a some experience for one of FreeBSD loaders I fixed earlier. It was very short (512 bytes if I am not mistaken) and just quick look on LLD and bfd linked hex views revealed the reason instantly. LLD linked binary was like corrupted with 4 bytes holes. All other code around was equal. That showed that we just did not apply one of relocations (R_386_16 I think) at all.

So main idea of dumping was to check if there is something obviously wrong. May be it was not the best idea :) I want to try though.

> Grepping around, it seems like they build this list of relocations based on some sort of homegrown tooling in arch/x86/tools/. E.g. look at arch/x86/tools/relocs.c.

So I am also suspecting it is something relative to relocations, my suspicion also based on fact that we had to
implement --emit-relocs option to support how they handle it.
This is new feature for LLD and can probably still may have bugs (last part was committed on this friday)? and needs testing.

Details about how they use --emit-relocs was in next comment: https://reviews.llvm.org/D28612#647277.
In short --emit-relocs generates .rel[a].xxx sections in output,
they extract these sections using objdump and wrap it into separate binary with own format.
And use this data for self-doing relocatations.

George.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170219/3ce0626d/attachment-0001.html>