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

[Peter Maydell]

On 23 July 2017 at 21:58, Hua Yanghao <address@hidden> wrote:
>> (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)
> I am not sure if I understood this point. linker will check for
> section overlaps and if linker
> did not complain why should qemu complain. qemu should simply follow
> the LMA for each
> section and ignore NOLOAD section for me this is the sane behavior.

Suppose we have these two segments:
 SEGMENT 1: start 0x1000, end 0x2fff, data all 0xff
 SEGMENT 2: start 0x2000, end 0x3fff, data all 0x00

Clearly for the memory 0x1000..0x1fff we want the 0xff
data, and for 0x3000..0x3fff we want 0x00.
But for the memory 0x2000..0x2fff which is in
both segment 1 and segment 2, should QEMU load
0xff or 0x00 bytes ?

We shouldn't pick randomly or just do whatever our
implementation "happens to do" -- we need to look
at what the ELF spec says must happen and do that.

>> (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)
> I think this should only apply for ELF files. (this is the only thing
> I care or understood so far,
> so not touching other types of input binaries ... however I am not
> sure if I am capable to provide
> a right patch to handle the ROM files properly, I only looked into
> qemu code starting today ...)

The patch you have here will affect QEMU's handling
of ROMs of all types, because the loader.c code
handles all the registered ROM images, not just those
that the ELF loader creates from ELF files.

(PS: these questions are partly aimed at the other
QEMU developers who I cc'd, not just you.)

thanks
-- PMM