qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] hw/core/loader: do not check for regions overlap
Date: Mon, 24 Jul 2017 17:46:52 +0100

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

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]