From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA05003 for caml-red; Sun, 3 Dec 2000 23:21:21 +0100 (MET) Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA08117 for ; Fri, 1 Dec 2000 17:50:36 +0100 (MET) Received: from localhost.localdomain (ppp163.dyn146.pacific.net.au [210.23.146.163]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id eB1GoTj01967; Fri, 1 Dec 2000 17:50:30 +0100 (MET) Received: from ozemail.com.au (IDENT:root@localhost [127.0.0.1]) by localhost.localdomain (8.9.3/8.8.7) with ESMTP id DAA12547; Sat, 2 Dec 2000 03:49:07 +1100 Message-ID: <3A27D683.5C34212E@ozemail.com.au> Date: Sat, 02 Dec 2000 03:49:07 +1100 From: John Max Skaller X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: fabrice.le_fessant@inria.fr CC: Vitaly Lugovsky , caml-list@inria.fr Subject: Re: Dynamic loading. Again. References: <14885.12770.825697.215308@cremant.inria.fr> <3A25FB93.AD27098B@ozemail.com.au> <14886.31615.260102.716998@cremant.inria.fr> <3A27A099.4EF5F3BD@ozemail.com.au> <14887.46228.317525.40290@cremant.inria.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: weis@pauillac.inria.fr 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