Page 1 of 1
GRUB - order in which are sections loaded
Posted: Wed Jan 18, 2006 8:26 am
by 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
Re:GRUB - order in which are sections loaded
Posted: Wed Jan 18, 2006 9:03 am
by 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?
Re:GRUB - order in which are sections loaded
Posted: Wed Jan 18, 2006 9:35 am
by 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.
Re:GRUB - order in which are sections loaded
Posted: Wed Jan 18, 2006 9:46 am
by 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
...)
Re:GRUB - order in which are sections loaded
Posted: Wed Jan 18, 2006 9:48 am
by superbabar
Oups, I forgot:
Thank you both!
Re:GRUB - order in which are sections loaded
Posted: Wed Jan 18, 2006 9:50 am
by Candy
superbabar wrote:
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.
Re:GRUB - order in which are sections loaded
Posted: Wed Jan 18, 2006 1:34 pm
by 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.
Re:GRUB - order in which are sections loaded
Posted: Thu Jan 19, 2006 3:45 am
by 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