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: Sun, 23 Jul 2017 21:44:37 +0100

On 23 July 2017 at 21:04, Hua Yanghao <address@hidden> wrote:
> From 84f25a8e4269f44255a8037837fdaa6e5404b76e Mon Sep 17 00:00:00 2001
> From: Hua Yanghao <address@hidden>
> Date: Sun, 23 Jul 2017 21:48:21 +0200
> Subject: [PATCH] hw/core/loader: do not check for regions overlap
>
> There is a use case where regions are overlapped on purpose.
> It should be up to the linker to check for regions overlap and qemu should
> better not to do so.
>
> For example:
> SECTIONS
> {
>     ...... /* the normal text/data */
>     _on_chip_ram_load_start = .;
>     . = . + SIZEOF(.on_chip_ram_section);
>     _on_chip_ram_load_end = .;
>
>     .bss (NOLOAD) {
>         *(.bss*)
>         *(COM*)
>     }
>     ...... /* other things */
> }

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

> with current hw/core/loader implementation, .bss section consumes no LMU 
> address
> space as .bss is not a loadable section, it is only useful for VMA at runtime.
> Where the .on_chip_ram_section is told to be loaded (LMA) from the VMA of .bss
> section. And qemu complains and exits. This patch fixes the issue and tested
> running fine for the above scenario.
> ---

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.

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)

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

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



reply via email to

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