On 23 July 2017 at 21:04, Hua Yanghao <huayang...@gmail.com> wrote: > From 84f25a8e4269f44255a8037837fdaa6e5404b76e Mon Sep 17 00:00:00 2001 > From: Hua Yanghao <yanghao....@intel.com> > Date: Sun, 23 Jul 2017 21:48:21 +0200 > Subject: [PATCH] hw/core/loader: do not check for regions overlap > > There is a use case where regions are overlapped on purpose. > It should be up to the linker to check for regions overlap and qemu should > better not to do so. > > For example: > SECTIONS > { > ...... /* the normal text/data */ > _on_chip_ram_load_start = .; > . = . + SIZEOF(.on_chip_ram_section); > _on_chip_ram_load_end = .; > > .bss (NOLOAD) { > *(.bss*) > *(COM*) > } > ...... /* other things */ > }
(I'm not sure why you end up with overlapping program segments here since the bss segment ought to be marked NOLOAD and ignored by QEMU. But I've definitely seen overlapping segments myself where the segments overlapping both are marked as LOAD.) > with current hw/core/loader implementation, .bss section consumes no LMU > address > space as .bss is not a loadable section, it is only useful for VMA at runtime. > Where the .on_chip_ram_section is told to be loaded (LMA) from the VMA of .bss > section. And qemu complains and exits. This patch fixes the issue and tested > running fine for the above scenario. > --- Oddly enough, I just ran into this scenario with an ELF file myself the other day, and worked around it with pretty much the same kind of local hack as this. I agree that since this kind of ELF file with overlapping segments seems to be quite common we should load it, rather than complaining. But... (1) does this change give the right behaviour for which of the two overlapping segment is honoured? (I *think* the correct answer is that the second segment in the program header table should be loaded second, ie its definition of the memory contents is used, not that of the first segment) (2) should we allow the overlap only for ELF files but retain the complain for overlapping ROMs of other types? (eg by having the elf loader create "rom"s which don't overlap by trimming the overlap itself) Does anybody know (a) what the ELF spec mandates for overlapping segments and (b) what the history and rationale for QEMU's overlapping-roms check is? thanks -- PMM