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

[Hua Yanghao]

> (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.)
Looks like qemu is not ignoring NOLOAD seciton check and used its VMA
as if it is LMA ...
If I remove the NOLOAD then .bss consumesthe LMA addresss and
everything is working fine.

> 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.
Good to know I am not the only one who hit this issue ;-)

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

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

> 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