Mail Archives: djgpp-workers/2001/12/20/00:08:58
As promised some time back, I've started to look at dynamic linking.
I first looked at the two DLL type packages on Simtel. Both of them
have nice features, but are a little heavy for what I am looking for.
I also looked at what DXE does and my 1995 notes, and see the plans
for expansion still look feasible and backward compatible.
The first thing I'm looking at is making DXEGEN be able to support
exports and imports. I can even have it automatically create an
export template for all symbols if one doesn't exist. If you want
to export variable/memory locations you would need to edit the
template (default would be assuming all exports are routines).
Imports would automatically be handled at load time.
The current DXEGEN stuff and DXEs would continue to work the exact
same way. The external symbol could also be the pointer to a
transfer vector (containing version, transfers) which was created
by DXEGEN from the export template. Imports would be stored after
the end of the current data image. A lib load stub for each library
would be created and available to link against which would find/load
the right library and provide the needed jumps. You could get
static or dynamic linking to any routine(s) by linking the
right way. I see DXEGEN doing all this dirty work at build time
based on defaults and a transfer definition file. This would allow
the load code to be small and fast.
Some new hook in dxeload to store the imports for later processing
or to process them would be needed. Implementation would depend on
size of added code and if we plan to start distributing things
linked against external libraries. I suspect this will be one
additional "for loop" once the data structures are set up.
The dxeload code would save the "malloc" value into a new external
variable which could be used to unload the image.
The current dxeload code needs _open, _read, _close, malloc, errno.
These (and what they call) would need to be in the base image.
Malloc bugs me (since I'd like to be able to replace it on the
fly - so maybe sbrk should be an option - unloadable). I haven't
looked at the list of what all would need to be loaded into the
core.
One thing we may need to do is break up some of the modules in
the library. In many cases we have many modules and external variables
in the same file (and thus the same object). To be able to move
some of this stuff to an optional external module, they may need to
be separate. Some of my original code is some of the worst examples :-(
A dlopen type interface would be possible, but it's not high on my
priority list.
Thoughts and comments? Higher priorities? I suspect this shouldn't take
more than a couple of hours to implement the enhanced DXE stuff.
Starting to use it will take a bit more time...
If the 2.04 distribution supports the enhanced DXEGEN you could
potentially ship the shared libraries later.
- Raw text -