Re: Dynamic Linking (was OOC Core Library)

[acken@informatik.uni-kl.de]

   From: Guy Laden <laden@math.tau.ac.il>

   [...]

   At first at least, perhaps we could use existing Oberon-Systems as dynamic
   linkers/runtime envs?
   With V4 sources coming out...
   Could ooc produce Oberon V4 object files?

OOC can produce any object file format you want, as long as your
back-end supports it.  You have to look at dynamic loading in the
context of object file format, linker, and loader.

Object File Format
You can generate any format you want, but you have to keep in mind
that these files are used as input for the linker/loader.  If you want
to link with existing object files on your target machine, or link O2
files into existing software, you have to choose your target's
existing object file format.

Linker
Usually takes a number of object files and combines them into an
`executable', serving as input to the loader.  The linking process
looks at external references in the object files and resolves them as
far as possible, respectively asserts that they can be resolved at the
loading stage (by shared libraries, DLL, or whatever).  At this stage
C compilers find out if you are using names that aren't defined
anywhere or if a name is defined multiple times.  The executable's
file format is determined by the OS.

Loader
The final stage before a program is actually run.  Usually part of the
OS (or kernel, or whatever).  Takes an `executable', puts it into
memory, resolves the last dangling references (to shared libs), sets
up the heap, the stack, etc, and passes control to the program.


The Oberon System combines the linker/loader into a single stage,
getting rid of the intermediate `executable' step.  The result has
more in common with the above described loader than with the linker.
So, if you are contemplating to implement a dynamic loader, you have
to extend your run-time system with a function that
  1) gets an object file from disk and puts it into memory
  2) resolves all references from the loaded module to existing
     modules 
  3) sets up the module's global state (global variables)
  4) executes the module's body

I don't think that peeking at the Oberon V4 sources will be much of a
help.  Better take a look at your OS's loading mechanism...


-- Michael van A.