Am 03.08.2017 um 00:00 hat Anatol Pomozov geschrieben:
> Hello Richard
>
> Thank you for this useful information. I still learning about ELF and
> a lot of things are still unclear for me.
>
> On Mon, Jul 31, 2017 at 11:20 AM, Richard Henderson <r...@twiddle.net> wrote:
> > On 07/31/2017 10:21 AM, Anatol Pomozov wrote:
> >> ELF sections info is needed for an OS to map address space properly.
> >
> > No, ELF *program header* info is needed for an OS to map the address space
> > properly. For example:
> >
> > $ readelf -hl vmlinux-4.9.0-3-5kc-malta
>
> Thanks for this information about program headers. I reread elf_ops.h
> and now I see that QEMU loads all PT_LOAD segments. I wonder why GRUB
> bootloader loads also sections that are not in this segment (e.g. GRUB
> loads content of .shstrtab into target's memory despite my elf does
> not keep it in PT_LOAD segment).
Remember that what we're talking about isn't primarily an ELF loader,
but a Multiboot loader. Multiboot can work without ELF (e.g. with flat
binaries) if bit 16 in the Multiboot header flags is set and the
additional header fields are correctly provided. However, if you are
loading an ELF binary, then Multiboot specifies that the bootloader
makes use of the ELF headers and you don't have to set bit 16 in the
header.
If ELF says that some things have to be loaded (and bit 16 is clear),
then the bootloader will load them. If Multiboot says that additional
things can or have to be loaded, it will load those, too. The section
headers are only one example of additional data that Multiboot provides.
It also loads additional modules, provides the e820 memory map, etc.,
none of which are described by ELF.
> What ELF specification says about it? Does it tell a loader to load
> only PT_LOAD segments? In this case bootloaders should follow it as
> well and current QEMU behavior is correct.
The current behaviour of QEMU is correct because it doesn't set bit 5 in
the flags field of the Multiboot info struct, i.e. it doesn't advertise
that the section headers are available, so it doesn't have to provide
it.
It is also not feature complete, because a full Multiboot implementation
would implement this and advertise bit 5. Adding the feature would be
useful because there are guest kernels that can make use of it.
> But multiboot expects section headers info and .shstrtab section to be
> loaded to the target memory. I believe I need to modify my linker
> script and add this information into the loadable segment.
No. First of all, you don't even need this information to find the start
and end of the kernel code. Second, if a Multiboot loader loads this, it
doesn't have to be in a loadable segment. This is more like debug
information, not like an inherent part of the program.
> Here is my current linker script:
>
> ======================
> ENTRY(start)
>
> SECTIONS {
> . = 1M;
>
> .text : {
> KEEP(*(.data.multiboot))
> *(.text .text*)
> }
>
> .rodata : {
> *(.rodata .rodata*)
> }
>
> .data : {
> *(.data .data.*)
> }
>
> .bss : {
> __bss_start = .;
> *(.bss .bss*)
> . = ALIGN(8);
> __bss_end = .;
> }
> }
> =======================
>
> With my linker script only .text .rodata .data and .bss are included
> into the loadable segment.
>
>
> So my questions: how to tell the linker to include "section headers"
> and ".shstrtab" section into loadable segment? Once it is done I can
> try to modify QEMU to pass its addresses to the target.
Requiring section headers to be contained in a loadable segment wouldn't
be a correct implementation of the Multiboot feature.
Kevin
