On 23 July 2017 at 21:44, Peter Maydell <peter.mayd...@linaro.org> wrote: > 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?
Having asked around a bit, it appears that it's fairly common in the embedded world to treat the ELF "vaddr" as the "execution address" and the ELF "paddr" as "load address", with the size of the data to be loaded at the load address being specified by "filesz". The typical application is where an application is packed into ROM -- the ROM addresses are the paddr values, and something at runtime will unpack everything into the vaddr addresses where it eventually runs from (and handle the zero-initialization). The awkward part is that this is more pervasive convention rather than actually written down as a specification, and there's no way to tell whether a particular ELF file is using it or not. My current theory is that we can handle this with: * load the segment with the assumption that the memsz is the size to use (zero-filling), as we do now * _unless_ that would make it overlap with the following segment, in which case use the filesz That ought to make all the ELF files we currently load OK continue to load with the same semantics, and also permit loading of ELF files using the ARM embedded conventions. In some cases of ELF files using the embedded convention but not tightly packing their segments into ROM it will zero out some of the gaps between segments, but I think that should be harmless. thanks -- PMM
