29jm / SnowflakeOS

"It is very special"
https://jmnl.xyz
MIT License
316 stars 18 forks source link

Elf loader #29

Closed xadaemon closed 2 years ago

xadaemon commented 3 years ago

draft elf loader

xadaemon commented 3 years ago

This is very incomplete and experimental (turns out loading elf is a bit of a pain)

29jm commented 3 years ago

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 !

29jm commented 3 years ago

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.

xadaemon commented 3 years ago

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 return ELF_OKAY or something.

thanks I will make those organization changes

29jm commented 3 years ago

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:

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?

xadaemon commented 3 years ago

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

29jm commented 3 years ago

Alright!

29jm commented 3 years ago

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 :)

xadaemon commented 3 years ago

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

29jm commented 2 years ago

Hi Matheus! I'm closing this PR for the time being, don't hesitate to reopen if you feel like going back to it :)