search for: bss16

...l_to_prot+0x8): relocation truncated to fit: R_X86_64_16 against symbol `rm_ds' defined in .text16.data.rm_ds section in bin-x86_64-efi/blib.a(librm.o) bin-x86_64-efi/blib.a(librm.o): In function `real_to_prot': (.text16.real_to_prot+0x22): relocation truncated to fit: R_X86_64_16 against `.bss16.rm_virt_addrs' bin-x86_64-efi/blib.a(librm.o): In function `real_to_prot': (.text16.real_to_prot+0x2e): relocation truncated to fit: R_X86_64_16 against `.bss16.rm_virt_addrs' bin-x86_64-efi/blib.a(librm.o): In function `real_to_prot': (.text16.real_to_prot+0x33): relocation truncat...

...n truncated to fit: R_X86_64_16 > against symbol `rm_ds' defined in .text16.data.rm_ds section in > bin-x86_64-efi/blib.a(librm.o) > bin-x86_64-efi/blib.a(librm.o): In function `real_to_prot': > (.text16.real_to_prot+0x22): relocation truncated to fit: R_X86_64_16 > against `.bss16.rm_virt_addrs' > bin-x86_64-efi/blib.a(librm.o): In function `real_to_prot': > (.text16.real_to_prot+0x2e): relocation truncated to fit: R_X86_64_16 > against `.bss16.rm_virt_addrs' > bin-x86_64-efi/blib.a(librm.o): In function `real_to_prot': > (.text16.real_to_prot+...

...R_X86_64_16 >> against symbol `rm_ds' defined in .text16.data.rm_ds section in >> bin-x86_64-efi/blib.a(librm.o) >> bin-x86_64-efi/blib.a(librm.o): In function `real_to_prot': >> (.text16.real_to_prot+0x22): relocation truncated to fit: R_X86_64_16 >> against `.bss16.rm_virt_addrs' >> bin-x86_64-efi/blib.a(librm.o): In function `real_to_prot': >> (.text16.real_to_prot+0x2e): relocation truncated to fit: R_X86_64_16 >> against `.bss16.rm_virt_addrs' >> bin-x86_64-efi/blib.a(librm.o): In function `real_to_prot': >> (....

...ged ldlinux.asm and extlinux.asm on the fsc branch, observing that there were very little difference between them left. So far, so good. I found, however, a test which fails on the fsc branch (with or without the merge.) I have tracked it down to vfat_mangle_name() overwriting a bunch of random .bss16 memory, eventually including the CallbackSP variable. http://www.zytor.com/~hpa/syslinux/fattest.tar.bz2 -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

...load) */ - . = 0x1000; - - .earlybss (NOLOAD) : { - HIDDEN(__earlybss_start = .); - *(.earlybss) - HIDDEN(__earlybss_end = .); - } - HIDDEN(__earlybss_len = ABSOLUTE(__earlybss_end) - ABSOLUTE(__earlybss_start)); - HIDDEN(__earlybss_dwords = (__earlybss_len + 3) >> 2); - - . = ALIGN(4); - .bss16 (NOLOAD) : { - HIDDEN(__bss16_start = .); - *(.bss16) - HIDDEN(__bss16_end = .); - } - HIDDEN(__bss16_len = ABSOLUTE(__bss16_end) - ABSOLUTE(__bss16_start)); - HIDDEN(__bss16_dwords = (__bss16_len + 3) >> 2); - - . = ALIGN(4); - .config : AT (__config_lma) { - HIDDEN(__config_start = .);...

From: Sylvain Gault <sylvain.gault at gmail.com> These patches basically remove unused linker scripts and port a change that was made to an unused script. Those are to be applied on top of the gcc 5 bug fixes as they would conflict otherwise. Sylvain Gault (4): diag/mbr: fix dependency to linker script Remove unused linker scripts core: Make symbols defined in linker script HIDDEN

...or ld since its content shouldn't be included into the binary file. Signed-off-by: Celelibi <celelibi at gmail.com> --- Again, I'm not 100% positive about the semantics of NOLOAD in a linker script. However I found this make things work better. Actually the file core/fs/fs.o have a .bss16 section that is not empty. If I understood correctly, only .bss can be empty in a .o. Thus ld generates the zeros that belong to that section in the .o. Then, when merging the section .bss16 into the .bss of syslinux.so, ld is forced to generate ALL the zeros that belong to the .bss section. Markin...

.... While searching for another option I determined that the problem seems to stem from the BIOS storing some information in the memory range 0x47CC-0x47FF, which is overwritten when PXELINUX loads. I couldn't figure out a clean way to avoid that memory region as it falls in the middle of the 4.x bss16 region, so I decided to create a copy of it instead. By copying that information out of the way during PXELINUX initialization and copying it back before returning control via 'localboot 0', the computer successfully boots to the local disk. Below is a patch again st commit 0a0e0e41cad93cd1...

...ree.c, mem/init.c */ extern void *malloc(size_t); extern void *lmalloc(size_t); diff --git a/core/parseconfig.inc b/core/parseconfig.inc index e7b3108..f28a68e 100644 --- a/core/parseconfig.inc +++ b/core/parseconfig.inc @@ -441,6 +441,7 @@ SerialNotice db 1 ; Only print this once section .bss16 alignb 4 +global VKernelEnd VKernelEnd resd 1 ; Lowest high memory address used ; This symbol should be used by loaders to indicate @@ -470,6 +471,7 @@ IPAppend db 0 ; Default IPAPPEND option section .uibss alignb 4 ; For the good of REP MOVSD +global command_lin...

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

The PE headers of the generated efi file were quite buggy. And since OVMF perform a few consistency checks, syslinux was unable to run on it. I don't pretend to have a thorough understanding of the PE+ headers, some bugs may remain. :) Celelibi (4): efi: Fix PE header field rva_and_sizes_nr efi: Location, size and alignment of .text section efi: Useless relocations in PE file efi: PE

This set of patches add some support for sector size >512. Currently it fixes extlinux, MBR for GPT and ext partitions. Other code is unaffected. This set of patches has been tested on a read Dell machine running a beta firmware.