Closed xadaemon closed 2 years ago
This is very incomplete and experimental (turns out loading elf is a bit of a pain)
A fine start! I'd suggest a few git acrobatics to get started on a clean history (stash any new non commited changes prior to doing this, and keep references to un-pushed commits so you can cherry-pick them back afterwards) :
git fetch upstream elves
git reset --hard upstream/elves
(took the liberty to remove the ".idea/*" changes from the commit too)
edit: and when you're done, git push --force origin elf-loader
!
Related to code organization:
edit: also really not sure about using errno kernel side, it'd be a first (although admittedly, using it in this libc would also be a first). I think what would be best would be to have those bool
functions return the error codes, and their caller will just check whether they return ELF_OKAY
or something.
Related to code organization:
* don't put kernel headers in sub directories of kernel/include/kernel, all same level * you can merge elf.h and elf_errno.h, kernel headers are already considered public interfaces for the other parts of the kernel (things that are intented to stay hidden should be defined at the top of the source file)
edit: also really not sure about using errno kernel side, it'd be a first (although admittedly, using it in this libc would also be a first). I think what would be best would be to have those
bool
functions return the error codes, and their caller will just check whether they returnELF_OKAY
or something.
thanks I will make those organization changes
I've had a good look at the elf spec (this one to be precise, though it seems to be a subset of that one), and while it's a complex format it still looks reasonable if we avoid relocation or dynamic linking-related things. I think we'll make it ok ^^
A first pass design would be a function like this
elf_error_t elf_load(const uint8_t* file, uint32_t size, uintptr_t* directory);
It'd return any error encountered, and if none, *directory
would be the physical address of a paging directory properly setup with program segments at the right place, as described in the program header of the elf file passed as the (file, size)
pair.
proc_exec
would then be in charge of:
elf_load
proc_run_code
) in the returned page directoryprocess_t
scheduler->sched_add
with that new process.On the elf side, this implies writing a function that reads the program header (the location and length of which is in the elf header) and for each segment (as defined on page 33), deal with it: map it (figure out where! maybe using p_vaddr
is enough), copy its content (depends on PROGBITS or NOBITS and probably other stuff), or discard it, etc... I'll be happy to help with anything, including writing stuff, helper functions, whatever if you need.
What do you think?
I like the idea, and I think we can do it I had no time this week to work on this but I want to get something done this weekend I might even start from scratch or semi-scratch
Alright!
fwiw: I pushed a new commit on elves
, it changes module compilation to output elf files and sets things up for testing an elf_load
function (it just feeds it elf data). It also corrects a bug in the ext2 driver (well, remove an error which was in fact not a bug) encountered when reading elf files, or any other file with quite a few zeros in them. The bugfix I'll pull on master later, the rest is for reference :)
I would just like to let you know that I have not given up on this, but life happened essentially and derailed my plans to complete this one before mid feb into oblivion
Hi Matheus! I'm closing this PR for the time being, don't hesitate to reopen if you feel like going back to it :)
draft elf loader