search for: d28612

...lt as well). >Probably, the result could be better if the --emit-relocs option didn't fail and CONSTRUCTORS were supported. I really don't know what >to do about the assertion that I have commented out. I updated patch for --emit-relocs, now they do not fail: https://reviews.llvm.org/D28612 It looks to be important feature for self relocations, so it is not surprising it did not run without :) George.

...his point I'm able to link Linux kernel with LLD and objcopy doen't give me any errors. > >The versions are: > >Linux 4.10.0-rc5 (+ applied the patch from my previous message) >LLD 5.0.0 (https://github.com/llvm-mirror/lld db83a5cc3968b3aac1dbe3270190bd3282862e74) (+ applied D28612) >GNU objcopy (GNU Binutils) 2.27 > >The problem is that the resulting kernel doesn't boot. Does anybody have any suggestions on how to debug it or any guesses what did go wrong while linking? > >Regards, >Dmitry It should not boot atm, I believe. I mentioned earlier, LLD cur...

On Fri, Jan 27, 2017 at 1:31 PM, Rui Ueyama <ruiu at google.com> wrote: > Sean, > > So as you noticed that linker script tokenization rule is not very trivial > -- it is context sensitive. The current lexer is extremely simple and > almost always works well. Improving "almost always" to "perfect" is not > high priority because we have many more high

...0-rc5 (+ applied the patch from my previous message)</div> <div>>LLD 5.0.0 (<a href="https://github.com/llvm-mirror/lld">https://github.com/llvm-mirror/lld</a> db83a5cc3968b3aac1dbe<span>3270190</span>bd<span>3282862</span>e74) (+ applied D28612)</div> <div>>GNU objcopy (GNU Binutils) 2.27</div> <div>> <br /> </div> <div>>The problem is that the resulting kernel doesn't boot. Does anybody have any suggestions on how to debug it or any guesses what did go wrong while linking?</div&gt...

...be better if the --emit-relocs option didn't >> fail and CONSTRUCTORS were supported. I really don't know what >to do about >> the assertion that I have commented out. >> >> I updated patch for --emit-relocs, now they do not fail: >> https://reviews.llvm.org/D28612 >> It looks to be important feature for self relocations, so it is not >> surprising it did not run without :) >> >> George. >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lis...

...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... U...

>>> - D28094 (Implemented support for R_386_PC8/R_386_8 relocations) >> Do you remember where it was used ? > >setup.elf: > ld.lld -m elf_i386 -T arch/x86/boot/setup.ld arch/x86/boot/a20.o arch/x86/boot/bioscall.o arch/x86/boot/cmdline.o arch/x86/boot/copy.o arch/x86/boot/cpu.o >arch/x86/boot/cpuflags.o arch/x86/boot/cpucheck.o arch/x86/boot/early_serial_console.o

...#39;m able to link Linux kernel with LLD and objcopy doen't > give me any errors. > > The versions are: > > Linux 4.10.0-rc5 (+ applied the patch from my previous message) > LLD 5.0.0 (https://github.com/llvm-mirror/lld > db83a5cc3968b3aac1dbe3270190bd3282862e74) (+ applied D28612) > GNU objcopy (GNU Binutils) 2.27 > > The problem is that the resulting kernel doesn't boot. Does anybody have > any suggestions on how to debug it or any guesses what did go wrong while > linking? > Based on our experience getting FreeBSD working, we spent most time getting...

>>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