ELF loading question
ELF loading question
I've got a question about loading ELF (just a quick theory question, I don't know if I'll use ELF in my OS...). So when I load ELF, the binary expects to be loaded at a specific address. Using segmentation I could make it think it's there, but that would cause problems when passing pointers to the kernel via system calls.
Do I basically load it in where it sais in the binary (e.g. address 0xC880)?
I'm confused...
Do I basically load it in where it sais in the binary (e.g. address 0xC880)?
I'm confused...
Re: ELF loading question
Hello,
I'm pretty new to OS Dev myself, but you can specify the loading address in your Linker script. This has been working for me. I'm not all that good with LD scripts, so it might be a bit off/strange, but it does work. Depending on your linker you might have to specify to output to ELF in the script.
The 5th line is what you would want to set. The section after that is for Grub, so you may not need it.
This boots with Grub .96 for me.
I'm pretty new to OS Dev myself, but you can specify the loading address in your Linker script. This has been working for me. I'm not all that good with LD scripts, so it might be a bit off/strange, but it does work. Depending on your linker you might have to specify to output to ELF in the script.
Code: Select all
OUTPUT("kernel.elf")
ENTRY(amain)
SECTIONS {
. = 0x00100000;
.__mbh ALIGN (4096) : {
*(.__mbh)
}
.text ALIGN (4096): {
*(.text)
*(.rodata)
}
.data ALIGN (4096) :{
*(.data)
}
.bss ALIGN (4096): {
*(.bss)
}
}
This boots with Grub .96 for me.
Re: ELF loading question
In the simplest case, all you need to do is read the program segment table. It'll tell you what pieces of the file to load to which addresses and if that chunk of data should be read-only, executable, etc. If memory size is greater than file size, zero the remainder. I would load the ELF file somewhere, and then copy the data when the segment is not page aligned.
EDIT: Sachot, the OP's question was on loading an ELF (as in the OS executing a program), not using ELF AS the kernel binary.
EDIT: Sachot, the OP's question was on loading an ELF (as in the OS executing a program), not using ELF AS the kernel binary.
Re: ELF loading question
So I have to set up the SEGMENTS in the GDT for user mode as the file shows?Hangin10 wrote:In the simplest case, all you need to do is read the program segment table. It'll tell you what pieces of the file to load to which addresses and if that chunk of data should be read-only, executable, etc. If memory size is greater than file size, zero the remainder. I would load the ELF file somewhere, and then copy the data when the segment is not page aligned.
EDIT: Sachot, the OP's question was on loading an ELF (as in the OS executing a program), not using ELF AS the kernel binary.
And yes, Sachot, I meant to LOAD the ELF, NOT use it as the kernel
Re: ELF loading question
Hey, I think I misunderstood. What if the program wants to be loaded right over my kernel?Hangin10 wrote:In the simplest case, all you need to do is read the program segment table. It'll tell you what pieces of the file to load to which addresses and if that chunk of data should be read-only, executable, etc. If memory size is greater than file size, zero the remainder. I would load the ELF file somewhere, and then copy the data when the segment is not page aligned.
EDIT: Sachot, the OP's question was on loading an ELF (as in the OS executing a program), not using ELF AS the kernel binary.
Re: ELF loading question
As for segments, the word does not refer to the GDT. They might as well just called them "regions" or "chunks". Mostly the same properties apply to paging (user privilege, read-only (technically optional?), executable (for PAE paging)).
Why would you allow that? An executable should only be loaded into userspace. An executable attempting to load into kernel space would be invalid (ie catch that, kill the process, show the user an error).
Why would you allow that? An executable should only be loaded into userspace. An executable attempting to load into kernel space would be invalid (ie catch that, kill the process, show the user an error).
Re: ELF loading question
You can either load it where it wants to be physically or use virtual addressing (in which case depending on your multitasking setup, could actually load at the same address as the kernel, or at least trick it to think it has). Virtual addressing can be confusing when passing pointers between processes you'll defiantly want a plan like shared memory or system calls. The first elf file I loaded was a while(1) loop so it didn't care where I put it in memory and I built from there...
Re: ELF loading question
I don't understand about these relocations... if i relocate the process, wouldn't that make all addresses in the file invalid?berkus wrote:You can make ELF with relocations...
Re: ELF loading question
'Relocating' a process means moving the process and modifying addresses as necessary to keep them all valid.mariuszp wrote:I don't understand about these relocations... if i relocate the process, wouldn't that make all addresses in the file invalid?berkus wrote:You can make ELF with relocations...
If a trainstation is where trains stop, what is a workstation ?
Re: ELF loading question
Well having loaded the process in the first place, the kernel would presumably know how to tanslate a pointer containing a segment offset into a "real" address. Nowadays it is more common to use paging to relocate programs in memory, and in 64 bit precessors AMD/Intel have actually disabled segmentation in 64 bit mode, so I would read up on paging and page tables if I were you.mariuszp wrote:I've got a question about loading ELF (just a quick theory question, I don't know if I'll use ELF in my OS...). So when I load ELF, the binary expects to be loaded at a specific address. Using segmentation I could make it think it's there, but that would cause problems when passing pointers to the kernel via system calls.
The advantage of paging is that it allows a program's apparently contiguous memory space to actually be scattered all over physical memory, in a way reminescent of file fragmentation on disk. The operating system and processor between them conspire to make it look (to the process) as if its fragmented memory is actually contiguous.