[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] ELF loader?
From: |
Liviu Ionescu |
Subject: |
Re: [Qemu-devel] ELF loader? |
Date: |
Sun, 7 Jun 2015 19:03:18 +0300 |
> On 07 Jun 2015, at 13:46, Peter Maydell <address@hidden> wrote:
>
> On 7 June 2015 at 09:19, Liviu Ionescu <address@hidden> wrote:
>> while debugging my Cortex-M code I added a trace in the ELF loader and I
>> noticed an odd thing:
>>
>> cortexm_mcu_image_load()
>> Load 10012 bytes at 0x08000000-0x0800271B.
>> Load 132 bytes at 0x0800271C-0x0800279F.
>> Load 704 bytes at 0x20000084-0x20000343. <---
>> Cortex-M3 core initialised.
>>
>> the first two lines load some bytes in flash, the third one loads some bytes
>> in ram. I checked the linker map and the ram range is actually the .bss
>> section.
>>
>> in other words, the .bss section is also "loaded". is this intentional, to
>> automatically reserve memory for that area? (since it obviously has no
>> content)
>
> ELF loaders ... look ... at the program headers, ...
> load everything marked LOAD.
a similar objdump on my ELF shows:
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0800010d
Program Header:
LOAD off 0x00008000 vaddr 0x08000000 paddr 0x08000000 align 2**15
filesz 0x0000271c memsz 0x0000271c flags rwx
LOAD off 0x00010000 vaddr 0x20000000 paddr 0x0800271c align 2**15
filesz 0x00000084 memsz 0x00000084 flags rw-
LOAD off 0x00010084 vaddr 0x20000084 paddr 0x20000084 align 2**15
filesz 0x00000000 memsz 0x000002c0 flags rw-
private flags = 5000202: [Version5 EABI] [soft-float ABI] [has entry point]
Sections:
Idx Name Size VMA LMA File off Algn
0 .isr_vector 00000354 08000000 08000000 00008000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .inits 00000028 08000354 08000354 00008354 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .data 00000084 20000000 0800271c 00010000 2**2
CONTENTS, ALLOC, LOAD, DATA
3 .data_CCMRAM 00000000 00000000 00000000 00010084 2**2
CONTENTS
4 .bss 000001c0 20000084 20000084 00010084 2**2
ALLOC
5 .text 000023a0 0800037c 0800037c 0000837c 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
6 .noinit 00000000 20000244 20000244 00010084 2**2
CONTENTS
7 ._check_stack 00000100 20000244 20000244 00010084 2**2
ALLOC
8 .comment 00000070 00000000 00000000 00010084 2**0
CONTENTS, READONLY
9 .ARM.attributes 00000031 00000000 00000000 000100f4 2**0
CONTENTS, READONLY
10 .debug_aranges 00000570 00000000 00000000 00010125 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_info 00006fc1 00000000 00000000 00010695 2**0
CONTENTS, READONLY, DEBUGGING
12 .debug_abbrev 00001cb6 00000000 00000000 00017656 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_line 00004c26 00000000 00000000 0001930c 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_frame 000015a8 00000000 00000000 0001df34 2**2
CONTENTS, READONLY, DEBUGGING
15 .debug_str 0005638f 00000000 00000000 0001f4dc 2**0
CONTENTS, READONLY, DEBUGGING
16 .debug_loc 00002dfd 00000000 00000000 0007586b 2**0
CONTENTS, READONLY, DEBUGGING
17 .debug_ranges 00000500 00000000 00000000 00078668 2**0
CONTENTS, READONLY, DEBUGGING
18 .debug_macro 00004519 00000000 00000000 00078b68 2**0
CONTENTS, READONLY, DEBUGGING
so, the reason for loading the .bss section is just the presence of the LOAD
flag for the first header.
> ... the loader will
> read some data from the file and set the rest to zeros.
> ... mandated by the ELF spec: you have to load the segments
> the file requests where it asks for them to go, and you have to
> zero-initialize any trailing parts.
:-)
this applies to large operating system loader, in the embedded world things are
a bit different.
> ... Some ELF files intended for embedded use have
> a little self-initializing bit on the front that manually clears
> their own .bss section, but that's not part of the ELF spec, and
> QEMU will handle the other kind too.
as I said, in the embedded world things are a bit different, there is no ELF
loader, or you can consider the debugger as an ELF loader since it is reading
the ELF file and programming the flash.
but during this step it makes no sense to write/clear the RAM, since what you
call 'a little self-initializing bit' is actually a quite complex startup code,
which must handle a table of RAM regions to be zeroed, plus that it must copy
the content of the .data section from flash to RAM (the second header in my
file, to be copied from 0x0800271c to 0x20000000).
so, in this case, as for most MCUs, loading the third RAM area is completely
useless, the embedded code *always* handle these details.
---
what is even more curious is that the third header is marked as load, although
the linker script is configured to remove the LOAD attribute from the header:
/* The primary uninitialised data section. */
.bss (NOLOAD) : ALIGN(4)
{
__bss_start__ = .; /* standard newlib definition */
_sbss = .; /* STM specific definition */
*(.bss_begin .bss_begin.*)
*(.bss .bss.*)
*(COMMON)
*(.bss_end .bss_end.*)
. = ALIGN(4);
__bss_end__ = .; /* standard newlib definition */
_ebss = . ; /* STM specific definition */
} >RAM
I'm either missing something, or the linker did not honour the script (NOLOAD)
property.
anyway, the problem is not harmful, it is more a curiosity for me, trying to
understand what is the expected qemu behaviour.
regards,
Liviu