> Yep, this is complaining because you have two LOAD > segments which overlap: > LOAD off 0x000000e0 vaddr 0x60000000 paddr 0x60000000 align 2**5 > filesz 0x0007773c memsz 0x00077c00 flags rwx > > which goes from 0x60000000 up to 0x600077bff, and > > LOAD off 0x00077820 vaddr 0x70000000 paddr 0x60077740 align 2**3 > filesz 0x00000038 memsz 0x00000038 flags r-x > > which starts at 0x60077740, in the middle of the previous one. > So should the loader honour the first of these segment > definitions (which says "fill it with zeroes", because the > memsz is greater than the filesz), or the second (which says > "fill it with data from the file") ? > Also, it has different rwx flags -- so are you asking for the > memory to be rwx or r-x ? (This kind of inconsistency is why > overlapping segments are weird.)
I don't quite understand how those load segments are created. Bear with me, from section point of view, 0x600077740 is both the .bss (which is NOLOAD) and the .lmu0 section. Why this bss section could end up in a loadable segments? I don't understand how those rwx/r-x permission are created from my linker script all memory regions share the same rwx attribute: 11 MEMORY 12 { 13 dram (rwx) : ORIGIN = CONFIG_DRAM_START, LENGTH = CONFIG_DRAM_SIZE 14 lmu0 (rwx) : ORIGIN = CONFIG_LMU0_START, LENGTH = CONFIG_LMU0_SIZE 15 lmu1 (rwx) : ORIGIN = CONFIG_LMU1_START, LENGTH = CONFIG_LMU1_SIZE 16 lmu2 (rwx) : ORIGIN = CONFIG_LMU2_START, LENGTH = CONFIG_LMU2_SIZE 17 } output/qemu_arm_vexpress/qemu_arm_vexpress.elf | sort | grep bss 60077738 B __bss_start 60077c00 B __bss_end from this link: http://nairobi-embedded.org/040_elf_sec_seg_vma_mappings.html It seems segments do consider NOLOAD .bss sections as part of loadable data segments. Does the loader needs to consider more things from the segments table to distinguish that the .bss section actually does not need to be touched? BR, Yanghao