Greg Haerr writes:
>
> 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.
Sounds cool.
>
> 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.
There are several reasons why this is not a serious obstacle. Firstly
if the program, take as an example microwindows, wants to be able to
load a device driver for the type of graphics card it is going to use.
The maximum size of the largest driver can be measured at compile time
at statically allocated in the code segment as follows:-
int module_init(arg)
int arg;
{
#asm
ret
.blkb TEXTSIZE-1
#endasm
}
This is not very flexible, but it would work, and was the way space was
allocated in a very primitive module system I build for ELKS with Rob's
help a while back. The system itself was basically useless, but making it
was educational. In the case of using your code to load kernel modules, the
kernel loader can be modified to leave the full 64K of the kernel code
segment allocated so there is room at the top for modules. Space would
also have to made available at the top of the ds. Actually writing the
code to the code segment is a case of writing a simple memcpy_tocs()
function.
>
> 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.
>
I assume by single import you mean that the module has a single linked
entry point? This would be no problem for driver modules for most things.
I would really love to see your code if I may.
Al
