[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "ELF-Symbols" tag for relocatable images

From: Andrei Borzenkov
Subject: Re: "ELF-Symbols" tag for relocatable images
Date: Sun, 26 Mar 2017 09:02:09 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

23.03.2017 14:41, Rodrigo V. G. пишет:
> On 3/23/17, Andrei Borzenkov <address@hidden> wrote:
>> 22.03.2017 22:23, Daniel Kiper пишет:
>>> On Wed, Mar 22, 2017 at 04:43:35PM +0100, Rodrigo Vali??a Guti??rrez
>>> wrote:
>>>>>> They also may not match if virtual address != physical address, but as
>>>>>> we do not establish any address translation when launching image, this
>>>>>> probably is going to fail. Still would be good to have this assumption
>>>>>> explicitly listed in multiboot2 manual.
>>>>> I think that we should state in multiboot2 spec that physical address
>>>>> ==
>>>>> virtual address in ELF.
>>>> That may be true (that is going to fail) for entry point address, but
>>>> please note that many kernels have the entry point and bootstrap code
>>>> in a section/segment with virtual == physical, but then setup address
>>>> translation and jump to another sections/segments with virtual !=
>>>> physical addresses.
>> Do those kernels use actually use ELF envelope for bootstrap part? We do
>> not really care what happens after payload is launched.
>> Can you give links to such kernels?
> Most kernels that I have seen (including hobby os) that use ELF, use
> it also for the bootstrap part, in a single binary. Even in x86_64
> they may use ELF64 with a bootstrap code in 32 bits included in a
> section that enables long mode and jumps to other sections with 64 bit
> code.
> And the multiboot (1 or 2 or both) header may be included in one of
> the first sections for easy detecting it, placed near the beginning of
> the binary file.
> The multiboot info tag structures about ELF may not be needed, though.
> Some links:
> Documentation that shows a linker script that loads at 0x00100000
> physical and 0xC0100000 virtual:
> http://wiki.osdev.org/Higher_Half_x86_Bare_Bones#linker.ld
> https://littleosbook.github.io/#higher-half-linker-script
> Documentation for linker scripts for x86_64 ELF64, where KERNEL_LMA
> may be 0x0000000000100000 (1MB) and KERNEL_VMA may be
> 0xffffffff80000000 (-2GB):
> http://wiki.osdev.org/Creating_a_64-bit_kernel#link.ld_2
> Also Minix3: Its linker script loads at 0x00400000 physical and some
> parts with the same virtual and other parts with 0xF0400000 virtual:
> http://git.minix3.org/index.cgi?p=minix.git;a=blob;f=minix/kernel/arch/i386/kernel.lds;h=24c0c1f90e8ca2c0e0abb89b1c1385522f26e115;hb=HEAD

OK, thanks; all of this just reinforces original report showing that
even without relocatable image sections may have address which is not
equal to physical address:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg
Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00
0   0  0
  [ 1] .note.gnu.build-i NOTE            c0100000 003000 000024 00   A
0   0  4
  [ 2] .text             PROGBITS        c0100030 001030 000269 00  AX
0   0 16
Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x001030 0xc0100030 0x00100030 0x003c0 0x003c0 R E 0x1000
 Section to Segment mapping:
  Segment Sections...
   00     .text .eh_frame .eh_frame_hdr

And apart from this ...

1. Documentation says

u16     | num               |
u16     | entsize           |
u16     | shndx             |
u16     | reserved          |

While the actual structure (both in multiboot1 and multiboot2) is

  multiboot_uint32_t size;
  multiboot_uint32_t num;
  multiboot_uint32_t entsize;
  multiboot_uint32_t shndx;

Which accommodates for both 32 and 64 but ELF.

2. Documentation says

"They correspond to the @samp{shdr_*} entries(@samp{shdr_num}, etc.) in
the Executable and Linkable Format (@sc{elf}) specification in the
program header".

Program Header has quite precise meaning in ELF, what is meant here is
obviously ELF Header.

3. I do not know what ELF specification was used as basis for this, but
I cannot find "shdr_num" anywhere. In ELF specifications I can reach
fields in ELF header are named


I do not think it is something that can be fixed in code. We only can
document current behavior with something like

"if section size is not 0 and section address in ELF file is 0, section
address will be set to physical address of section in memory. Note that
for loadable and allocatable sections (that are part of program
segments) address is set by linker to virtual address and may not
correspond to physical location in memory."

I still miss the actual use case for this tag which could help to
understand how it was supposed to be used.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]