Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!newstop!sun!amdcad!dvorak.amd.com!proton!tim From: tim@proton.amd.com (Tim Olson) Newsgroups: comp.os.minix Subject: Re: Shared libraries with minix Message-ID: <1991Jun4.041033.20792@dvorak.amd.com> Date: 4 Jun 91 04:10:33 GMT References: <3216@krafla.rhi.hi.is> <1991Jun1.043438.17038@watserv1.waterloo.edu> Sender: usenet@dvorak.amd.com (Usenet News) Reply-To: tim@amd.com (Tim Olson) Organization: Advanced Micro Devices, Austin, TX Lines: 52 In article klamer@mi.eltn.utwente.nl (Klamer Schutte) writes: | In <1991Jun1.043438.17038@watserv1.waterloo.edu> hbetel@watserv1.waterloo.edu (Heather Betel) writes: | | > My point is that this must happen even on MMU systems. On the | >8086, your model is fairly simple, but under, say, an 040, the library | >server is a different process, with a completely different memory | >space. Mapping in the client's space, doing the work, then mapping it | >out, for every call is expensive. | | Either i don't understand the problem, Richards idea of an MMU is too | simple, or my idea of an MMU is too complex ;-) | | It should be possible for an MMU (040 type) to have more than 3 segments | allowed to one process at one time. The segments which need to be in | current address space, and not causing a trap are (IMHO): | 1) user program. text, data (incuding bbs) and stack. | 2) trap handler. At least text. Perhaps data. Stack? | 3) Shared library code. At least text. Perhaps read-only data. The two of you appear to be looking at two slightly different ways to support shared libraries with an MMU. The big difference between them is whether the compiler/linker supports PIC (Position Independant Code) and Data, or not. If PIC is supported (most commonly through PC-relative branches and references in the code sections and base-register+offset addressing in the data sections), then a single physical copy of the library code could be mapped to any virtual address and still run correctly. The shared library code could then be mapped at runtime. This appears to be the method Mr. Schutte is discussing. Mr. (Not Heather!?) Betel, on the other hand, appears to assume non-PIC code/data. One solution to this kind of library is to map it into its own virtual address space, much like MM and FS, and create a library server process out of it. This would entail quite a bit of overhead for sending messages to the server and/or copying data in and out of the calling process' memory. Another (albeit grungy!) possibility for non-PIC systems is to fix the library's virtual addresses to well-known, otherwise unused virtual memory locations, and compile the library to use those addresses (e.g. printf() exists at 0xa0001234 in every process' address space). Then, the one physical copy of the library gets mapped to the same virtual address in each process at runtime. However, this type of shared-library mapping quickly becomes impossible to use when frequent changes to the libraries occur. -- -- Tim Olson Advanced Micro Devices (tim@amd.com)