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).
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.
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.
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.
>
> Using a mips kernel binary I happend to have handy; it would be the same for
> x86_64, prior to being bundled in the (imo superfluous bzImage) format.
>
> ELF Header:
> Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
> Class: ELF64
> Data: 2's complement, little endian
> Version: 1 (current)
> OS/ABI: UNIX - System V
> ABI Version: 0
> Type: EXEC (Executable file)
> Machine: MIPS R3000
> Version: 0x1
> Entry point address: 0xffffffff806ed590
> Start of program headers: 64 (bytes into file)
> Start of section headers: 13351328 (bytes into file)
> Flags: 0x80000001, noreorder, mips64r2
> Size of this header: 64 (bytes)
> Size of program headers: 56 (bytes)
> Number of program headers: 2
> Size of section headers: 64 (bytes)
> Number of section headers: 28
> Section header string table index: 27
>
> The ELF file header, always at file offset 0. The relevant info is the
> encoding (64-bit little-endian), cpu (mips), and start of program headers.
>
> Program Headers:
> Type Offset VirtAddr PhysAddr
> FileSiz MemSiz Flags Align
> LOAD 0x0000000000001000 0xffffffff80100000 0xffffffff80100000
> 0x00000000009fefb4 0x0000000000a5a150 RWE 1000
> NOTE 0x00000000005fecb0 0xffffffff806fdcb0 0xffffffff806fdcb0
> 0x0000000000000024 0x0000000000000024 R 4
>
> The ELF program header. There is one segment to be loaded, at a given
> physical
> address (which happens to match the virtual address, but that need not have
> been so).
>
> The segment consists of 0x9fefb4 bytes of data to be loaded from the file, and
> occupies 0xa5a150 in memory. The difference between the two sizes is "bss",
> and should be zeroed.
>
> A proper ELF loader will process *all* LOAD segments, however many are
> required
> by the binary. Though in practice there will probably only be 1 or 2.
>
> Section to Segment mapping:
> Segment Sections...
> 00 .text __ex_table __dbe_table .notes .rodata .pci_fixup __ksymtab
> __ksymtab_gpl __kcrctab __kcrctab_gpl __ksymtab_strings __param __modver .data
> .data..page_aligned .init.text .init.data .exit.text .data.reloc .sbss .bss
> 01 __dbe_table .notes
>
> This mapping is provided by readelf for convenience, not actually present in
> the ELF file. But it is handy when debugging a linker script.
>
>> Quoting Multiboot specification
>> https://www.gnu.org/software/grub/manual/multiboot/multiboot.html
>
> I'm not sure why someone felt the need to re-invent the wheel, especially
> considering its introduction section talks about trying to stop reinventing
> the
> wheel...
>
> But... whatever. I'm not sure why this is relevant to $SUBJECT, since it does
> not appear to have anything to do with ELF at all.
>
>
> r~
