Re: [Qemu-devel] ELF loader?

[Liviu Ionescu]

> 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