Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ub!galileo.cc.rochester.edu!rochester!udel!mmdf From: PAZZINI%BRUFSM@cunyvm.cuny.edu (Marcelo Pazzini) Newsgroups: comp.os.minix Subject: Re: Shared libraries with minix Message-ID: <56097@nigel.ee.udel.edu> Date: 12 Jun 91 12:23:24 GMT Sender: mmdf@ee.udel.edu Lines: 50 On Tue, 4 Jun 91 09:10:33 GMT Tim Olson said: >In article klamer@mi.eltn.utwente.nl >(Klamer Schutte) writes: >hbetel@watserv1.waterloo.edu (Heather Betel) writes: >| 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. I worked at a company which used a 68030 as the main processor, performing its own Unix-like OS. It had up to 16 segments for each program. They use one for text, one for data & stack, others for shared memmory, including libraries. I guess it works fine. >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 (stuff about position independant compiler) >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. Well, I only propose my method for a MMU based hardware. I guess it is not a good idea to add offsets at runtime. I would also say relocations at load time isn't good, but it cannot be avoided without hardware memmory control, say, in an 8088 (bleargh). I have the same problem on moving Minix for Transputers because they have no MMU, no segment control, nothing! >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. It will not happen if you use a jump table at the top of the library. And you can relocate it using a real Unix-like ld, with a scriptfile to do this. Hope it be useful for you, because I am not implementing this stuff. ;-) Marcelo Pazzini (pazzini@brufsm.BITNET) DELC - CT The child is grown, UFSM Campus The dream is gone, Santa Maria, RS And I have become, 97119 COMFORTABLY... TEACHER. BRASIL (BRAZIL if you're out of here!) (D.Gilmour, diff by me)