David
Program Loader
I have unix-side code which can interpret the ELF object/executable
code which gcc creates (by default). This code can retrieve symbol
information from the shared object (library, e.g. /lib/libc.so) and
show either display the file data or perform all the symbol lookups
that are needed to do the dynamic symbol resolution.
I ran into several problems.
- First, the unix-side program relies on the mmap() function to
efficiently allocate and address memory from the file on disk. But,
mmap() relies on the system having virtual memory (which our OS
lacks).
- Second, extracting the symbol table from the compiled kernel is
not as straight-forward as I had guessed it would be.
- Third, processing the executable format requires some difficult
memory allocation operations (which are trival with mmap()). It
turns out that the object file format (file.o) is much simpler to use
even though it requires the loader to do more work (which is usually
done by the linker at compile time).
- Lastly, I found that it may be possible to include a separate
memory manager for each thread. Though these would all use the same
address space, it will be possible to track with thread allocated
which memory blocks. This way, when a thread completes, it can free
all its memory automatically instead of relying on the programmer to
remove all memory leaks.
Switching to the object file format makes it easier to get around
the memory allocation problems (thought I still need to figure out how
to determine the size of the .bss section and include that in the
initially memory allocation).
Though the unix-side code for translating object files into an
executable image seems to be working, the resulting code does not seem
to execute correctly. I suspect that there are bugs in how I'm
understanding the process; I expect to have them figured out this week.