On Mon, Jul 24, 2017 at 11:21 PM, Peter Maydell
wrote:
> On 24 July 2017 at 21:03, Hua Yanghao wrote:
>> 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 + 0x1. From man page
>> it claims
On 24 July 2017 at 21:03, Hua Yanghao wrote:
> 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 + 0x1. From man page
> it claims it also supports multiboot image which I thought I could
> re
On Mon, Jul 24, 2017 at 6:46 PM, Peter Maydell wrote:
> On 23 July 2017 at 21:44, Peter Maydell 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
On 23 July 2017 at 21:44, Peter Maydell 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
> In the bit of the spec you quote it says how p_memsz > p_filesz
> should be handled: "the 'extra' bytes are defined to hold the
> value 0". The segment itself is still p_memsz in size and the
> header defines that it has zeroes at the end of it. QEMU's loader
> needs to arrange that those zeroes
On 24 July 2017 at 13:21, Hua Yanghao wrote:
> I think I got where qemu went wrong, it should pick filesz instead of
> memsz, right? ;-)
>
> You see here the filesz does not actually include the bss section
> where if you only check the memsz then it overlaps.
>
> LOAD off0x00e0 vaddr
On Mon, Jul 24, 2017 at 2:09 PM, Hua Yanghao wrote:
>> Yep, this is complaining because you have two LOAD
>> segments which overlap:
>> LOAD off0x00e0 vaddr 0x6000 paddr 0x6000 align 2**5
>> filesz 0x0007773c memsz 0x00077c00 flags rwx
>>
>> which goes from 0x600
> Yep, this is complaining because you have two LOAD
> segments which overlap:
> LOAD off0x00e0 vaddr 0x6000 paddr 0x6000 align 2**5
> filesz 0x0007773c memsz 0x00077c00 flags rwx
>
> which goes from 0x6000 up to 0x600077bff, and
>
> LOAD off0x00077820 va
On 24 July 2017 at 12:42, Hua Yanghao wrote:
>> If you're hitting this error case then I think the
>> affected segments must both be of type PT_LOAD.
>> (If you're not sure you can post here the output
>> of running 'objdump -p' on the binary or otherwise
>> show us the program header.)
>
> Here
> I have seen ELF files which have this overlap and
> where both segments are PT_LOAD. (I think in the cases
> I've seen the contents in both segments agree rather than
> being different data, but a loader is not going to be
> expected to do a comparison of the file data.)
Hmm ... OK. there are def
On 23 July 2017 at 23:11, Hua Yanghao wrote:
>> 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 0x0
> 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
>
On 23 July 2017 at 21:58, Hua Yanghao 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 mem
> (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 sec
On 23 July 2017 at 21:04, Hua Yanghao wrote:
> From 84f25a8e4269f44255a8037837fdaa6e5404b76e Mon Sep 17 00:00:00 2001
> From: Hua Yanghao
> 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 overlappe
>From 84f25a8e4269f44255a8037837fdaa6e5404b76e Mon Sep 17 00:00:00 2001
From: Hua Yanghao
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
16 matches
Mail list logo
