search for: r_386_16

...linux-debug.lsr -o isolinux-debug.o isolinux-debug.asm ld -m elf_i386 -T syslinux.ld -M -o isolinux-debug.elf isolinux-debug.o > isolinux-debug.map ld: 64K overflow ld: 64K overflow isolinux-debug.o: In function `msg_filename': isolinux-debug.asm:(.text+0x202d): relocation truncated to fit: R_386_16 against `.bss1' isolinux-debug.o: In function `msg_viewimage': isolinux-debug.asm:(.text+0x2049): relocation truncated to fit: R_386_16 against `.bss1' ld: 64K overflow make: *** [isolinux-debug.elf] Error 1 Examining isolinux-debug.map, .bss1 seems to be ending just above the 64kiB ma...

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

I got a qemu crash and errors reported in bochs while trying to get latest core32 branch working (pxelinux): qemu: fatal: Trying to execute code outside RAM or ROM at 0xe6e8aa07 EAX=6e0c7811 EBX=000034b3 ECX=ca68b338 EDX=00000048 ESI=750e3fff EDI=00000020 EBP=d07e4988 ESP=00102324 EIP=e6e8aa07 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0028 00000000 ffffffff 00cf9300 CS =0020

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

This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 It also fixes a test which was requiring the *wrong* output. I'm relatively happy with this part, and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've