Re: Dynamic loading. Again.

[John Max Skaller <skaller@ozemail.com.au>]

Fabrice Le Fessant wrote:

> >   The per process data lives at the same address for
> > every process, but the underlying memory is swapped for
> > every task switch (at least, on the 486 this is done).
> 
> What about libraries mapped at the same address, 

	They can't be.

> or on overlapping
> segments ? They could be loaded first by different processes, 

	Only one library can be loaded at a time.
The loader must block while it is loading a library.
[At least, it must block while allocating the address space]

>then another one would want to use both of them and would not be able to
> map both of them !!! You MUST have position independent code if you
> really want your code to be SHARED.

	Suppose I load library X. It gets mapped to

	0xFF00-0000

Now suppose YOU load library X. It is already in memory.
The loader knows that. It gets mapped to

	0xFF00-0000

The same address for both of us.  Now I load Y, and you load Z.
Y loads first, under X. Then Z loads, under Y.
Or the other way around: the order doesn't matter, but the 
address space used had better be the same. We all share
the same physical memory at the same address (for the shared
libraries).

Perhaps there is a confusion here: ALL the code is built to
run at address zero. ALL the code is patched to the actual
load address. The address space for each library is allocated
so it cannot overlap, at the first load attempt. Subsequent
attempts to load the library simply refer to it at the 
address at which it is already loaded. Everyone maps the code
to the same address it is actually loaded at! This means
your code address space will consist of 'chunks' (with holes
for the loaded libraries you are not using).

In some sense, the library image is position independent, because
it can be loaded at any address. But this is a loader function,
not a property of the addressing modes of instructions used.

In the old days, I used to write assembler for code that was
loaded directly into memory straight off disk. This code
has to be position independent in the sense that there
was NO 'loader' to patch anything: the disk image was a
a memory image of the code, ready to run. So absolute
addressing was used only for reference to things like ROM
in fixed positions.

The problem is always the data, not the code. Relative jumps
and calls are easy. Its not so easy to do 'relative' data,
if there are many processes each requiring its own copy
of writable store: that required indirection through a register.
But these days, that indirection is provided by system level
hardware like VM, rather than an application register.

The reason is probably that application code cannot
EVER use real absolute addresses. Only the OS is allowed
to do that.  Instead, absolute addresses are translated
using an invisible 'register', there being no good reason
to waste an application register for the job. Why waste
bits specifying the register in the instruction set?
[I cite this argument without believing it :-]

-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net