Re: [Qemu-devel] [PATCH] hw/core/loader: do not check for regions overlap

[Hua Yanghao]

On Mon, Jul 24, 2017 at 6:46 PM, Peter Maydell <address@hidden> wrote:
> On 23 July 2017 at 21:44, Peter Maydell <address@hidden> 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).

That's exactly what I am doing right now ;-)
I have code at runtime not only initialize the bss, but also moving
a few other sections around (e.g. from dram to onchip memory).
And we even have use cases that the bss part should not be
initialized at all! (on accurate simulation env where the .bss is
preloaded with zeros, without overlapping sections of course)

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

Indeed, I thought this is the standard written somewhere :-)
Maybe I am just in the embedded world for too long.

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

Sounds good PPM! currently I am working around this by
objcopy a pure binary and it looks like qemu-system-arm is
loading a binary at loader address + 0x10000. From man page
it claims it also supports multiboot image which I thought I could
remove this loader address + 0x10000 limiation however with
no luck. but the binary works pretty fine though at the fixed address.
not as convenient as elf image which I can run from any address.

If this can be implemented in mainline I will be very happy but
my knowledge with qemu is probably not enough to make a clean
patch. Thanks a lot for the good discussion!

BR, Yanghao