GRUB - order in which are sections loaded

[superbabar]

Hi all!

Is it safe to assume that GRUB loads the sections from an elf executable in the order they are in the file?

There is nothing about this in the spec.
Has anyone issued some tests?!

I'm interrested in this because i'm aiming at determining what regions of memory are free once the kernel is loaded and running.
GRUB reports a map of memory, but not the map of free memory. For ex: GRUB reports the region from 0x100000 as "Available" (term used in the spec) even if the kernel is at 0x100000+

Thanks in advance

[Solar]

Hmmm... AFAIK, the kernel is loaded at the address you specified, either in the corresponding ELF field or the Multiboot address fields. The Multiboot data structure tells you where any modules have been loaded. That should be enough to update your memory map, or am I mistaken?

[Colonel Kernel]

Are you trying to determine if you can use some of the memory between the sections of your kernel executable? If so, I wouldn't bother. I use the load address and a special symbol from my linker script to determine what range the kernel image occupies:

Code: Select all

ENTRY (StartPrecursor)

OUTPUT_FORMAT(binary)
SECTIONS
{
   . = 0xE0000000 + 0x00100000;

   .text :
   {
      *(.text)
      *(.rodata*)
   }

   .data ALIGN (0x1000) :
   {
      *(.data)
   }

   .bss :
   {
      *(COMMON)
      *(.bss)
      BssEndPhys = . - 0xE0000000;   /* We want the physical address here. */
   }
}

Note that my kernel is in the higher half at the virtual address 0xE0000000, so I have to subtract that to get the physical addresses of the beginning and end of the kernel.

[superbabar]

Colonel Kernel >>

No, i want to know what regions of memory the kernel occupies to finally found what area of physical memory may be used.

The idea you've suggested is the first that came to my mind, but is it reasonable to think that the map passed to the linker will be respected by GRUB and will reflect the organisation of the kernel image loaded in memory. (is it defined in the ELF std?)

---------------------------------
Solar >>

That is what I plan to do, but I was wandering wheter grub could provide directly a map of *free* memory (you know the story about the wheel ...)

[superbabar]

Oups, I forgot:

Thank you both!

[Candy]

The idea you've suggested is the first that came to my mind, but is it reasonable to think that the map passed to the linker will be respected by GRUB and will reflect the organisation of the kernel image loaded in memory. (is it defined in the ELF std?)

---------------------------------
Solar >>

That is what I plan to do, but I was wandering wheter grub could provide directly a map of *free* memory (you know the story about the wheel ...)

[guru-style]

There is no free. There is no in-use. There is only memory.

[/guru-style]

The memory itself isn't free or in use. There is only memory, that you can consider in use or not in use.

Grub tells you (or you should tell Grub actually) where your kernel is / should come. So, you know that. You tell it where your modules go, so it knows that. So do you.

The rest is all free, except for the bits we've gathered on the wiki. That's mainly below 1M. If you keep all those bits in check, all stuff you don't explicitly use is free.

Grub doesn't need to provide a free map, you can make your own with less overhead.

[Colonel Kernel]

I think we're missing the intent of the original question -- is there something magical about loading ELF files that can scatter the different sections all over the place? I'm guessing the answer is "no", but in my case I use a flat binary, so I don't have that worry.

[Pype.Clicker]

if that helps ...

Code: Select all

src/kicker> objdump -h kicker.elf 

kicker.elf:     file format elf32-i386

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .init         000014a0  00100000  00100000  00001000  2**5
                  CONTENTS, ALLOC, LOAD, CODE
  1 .SOS          000004ff  00106000  00106000  00003000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  2 .rodata.str1.1 0000782f  001064ff  001064ff  000034ff  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .rodata.str1.32 0000806c  0010dd40  0010dd40  0000ad40  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .core         00029f04  00115db0  00115db0  00012db0  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  7 .system       00010004  00800000  00800000  00040000  2**0
                  CONTENTS, ALLOC, LOAD, DATA

which is loaded as
[tt]
[multiboot-elf, <0x100000:0x14a0:0x0>, <0x106000:0x3c7d4:0x282c>, <0x800000:0x10004:0x0>, shtab=0x8111e0, entry=0x100340]
[/tt]

that's not much the "sections" that will be used, but rather the "program header", which tells what to load, where, etc.

Code: Select all

kicker.elf:     file format elf32-i386
kicker.elf
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00100340

Program Header:
    LOAD off    0x00001000 vaddr 0x00100000 paddr 0x00100000 align 2**12
         filesz 0x000014a0 memsz 0x000014a0 flags rwx
    LOAD off    0x00003000 vaddr 0x00106000 paddr 0x00106000 align 2**12
         filesz 0x0003c7d4 memsz 0x0003f000 flags rwx
    LOAD off    0x00040000 vaddr 0x00800000 paddr 0x00800000 align 2**12
         filesz 0x00010004 memsz 0x00010004 flags rw-
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**2
         filesz 0x00000000 memsz 0x00000000 flags rwx