Al,
I've completed the runtime dynamic linking loader
produced by the 8086-based bcc, as86 and ld86 tools. This code
allows the relocatable images produced by as86 to be
loaded as shared libraries if desired. All export and import
symbols are matched, and offsets relocated. Currently,
it also allows for libc.a and other archive files to be searched,
and modules loaded as well. The relocating loader
also works for 32-bit object modules produced with the bcc -3
option.
However, there remains a very serious problem
relating to getting this to work in 16-bit mode. (I finally
realized this damn near after completing the whole thing)
Although I have it working for both 16 and 32 bit files now,
I can't actually execute the code loaded for 16 bit modules.
This is because I malloc() the data space for the code segment,
but the code has to actually execute relative to the CS segment.
Thus, we would need an additional system call, or the ability
to write into a new process space in order to allocate
code segment space and have it relative to the CS register.
So, I'm not sure what's next. (It's been a very informative project,
however... I can still run .o files created from bcc -3 in my native
linux elf programs...) If we wanted to add some very _new_
design to the ELKS kernel, we could add the abililty for ELKS
to load/unload modules, and the same loader code could be
used for user processes as well. The reason we'd use the current
.o file format is because we'd not have to write new tools.
The ELKS kernel could load/unload drivers using the same
mechanism that user programs use, which is cooler than the
Linux kernel's implementation. Unloading modules
is easy if there's a single import, but with multiple imports,
it gets harder.
Greg
