Re: [Qemu-devel] ELF loader?

[Peter Maydell]

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 don't look at the section table, they
look at the program headers, which describe the segments
in the program and typically look something like this:

Program Header:
    PHDR off    0x00000034 vaddr 0x08048034 paddr 0x08048034 align 2**2
         filesz 0x00000120 memsz 0x00000120 flags r-x
  INTERP off    0x00000154 vaddr 0x08048154 paddr 0x08048154 align 2**0
         filesz 0x00000013 memsz 0x00000013 flags r--
    LOAD off    0x00000000 vaddr 0x08048000 paddr 0x08048000 align 2**12
         filesz 0x00004658 memsz 0x00004658 flags r-x
    LOAD off    0x00004ef0 vaddr 0x0804def0 paddr 0x0804def0 align 2**12
         filesz 0x000001cc memsz 0x00000350 flags rw-
 DYNAMIC off    0x00004efc vaddr 0x0804defc paddr 0x0804defc align 2**2
         filesz 0x000000f0 memsz 0x000000f0 flags rw-
    NOTE off    0x00000168 vaddr 0x08048168 paddr 0x08048168 align 2**2
         filesz 0x00000044 memsz 0x00000044 flags r--
EH_FRAME off    0x00003d40 vaddr 0x0804bd40 paddr 0x0804bd40 align 2**2
         filesz 0x000001c4 memsz 0x000001c4 flags r--
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
         filesz 0x00000000 memsz 0x00000000 flags rw-
   RELRO off    0x00004ef0 vaddr 0x0804def0 paddr 0x0804def0 align 2**0
         filesz 0x00000110 memsz 0x00000110 flags r--

and we load everything marked LOAD. (This is /bin/true on my Linux
box, but the principle is the same for any ELF file.) This ELF file
has two LOAD segments. The first one is read-only and will have the
code in it; its filesz and memsz are the same, so the loader reads
all the content from the file. The second one is read-write, and its
filesz is smaller than the memsz (0x1cc vs 0x350). So the loader will
read some data from the file and set the rest to zeros. In this case
that's the .data section (and a lot of other stuff like GOT, PLT,
dynamic linker info, etc) followed by a .bss.

(Notice that the linker has put a number of different sections into
the same segment; the amount of info needed to load the file is
much simpler than the info needed by a linker, which is why ELF has
this dual segment/section view.)

This is all 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 ensures the .bss really
is zero-initialized. 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.)

-- PMM