TODO: update kernel a.out to ELF reader #7
Description
The GNU tools all fluently read and write ELF, so using that instead of a.out is a no-brainer for us.
I think most of our damage will be in sys1.c:getxfile(). ELF is well documented. This seems to be the code responsible for fondling the executable header, creating a mapping (or filling a buffer) to hold the executable, and keeping some sense of security around not executing garbage, not leaving partially filled pages in the programs address space, etc.
This could possibly developed before the filesystem code is in place by carefully creating an ELF executable in kernel address space, dummying up an inode, and calling it directly. Probably create a tiny "hello world" executable in user space, then use an #includebin to slurp it into kernel space during the build. Throw it in another section if you don't like it in .data, but be sure the linker script doesn't toss the section.