Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!uwvax!oddjob!ncar!ames!amdahl!nsc!glennw From: glennw@nsc.nsc.com (Glenn Weinberg) Newsgroups: comp.arch Subject: Re: Is the Intel memory model safe from NO-ONE ?!? Summary: Why do we have to do shared libraries wrong? Message-ID: <5064@nsc.nsc.com> Date: 13 May 88 16:50:38 GMT References: <3384@drivax.UUCP> <4053@killer.UUCP> Reply-To: glennw@nsc.UUCP (Glenn Weinberg) Organization: National Semiconductor, Sunnyvale Lines: 48 In article <4053@killer.UUCP> elg@killer.UUCP (Eric Green) writes: >There's one case where segmentation (of code) is a Big Win (segmentation of >data space is almost never a win): Shared libraries. I understand that Sys V.3 >has a kludge that reserves various places in a (linear) 32-bit address space >for certain libraries and types of libraries. This is necessary because the >libraries must appear at the same address in every process (because otherwise >they would need to be re-linked for each process, on most machines, which >don't support relocatable code -- thus throwing away all the advantages of ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >shared libraries). > >On a segmented machine, all shared libraries could start at address 0, in >different segments in different processes. It is a much more elegant solution >than chopping your address space in such a manner that you cannot have two >windowing libraries loaded at the same time. <> This is the kind of thing that really frosts me. "Oh, gee, no one wants to take the trouble to build relocatable code, so let's just come up with a kludgey solution rather than doing it right." There is absolutely no reason why language tools and software practices cannot be changed starting immediately to produce relocatable code. Most companies are already rebuilding their tools for RISC architectures anyway. It's just not that hard to write relocatable code from a programming point of view (I was doing it 10 years ago!). It's also not that hard to write code to support relocatable shared libraries. It's yet another of those things that Multics supported over 20 years ago, but that we somehow seem to believe is "just too hard" to do now. When I was at Prime 8 years ago (I know all about the lousy reputation Prime has in the Un*x community) we had shared libraries and were developing relocatable shared libraries. We had dynamic linking for system calls, too. It's not like the technology doesn't exist! Of course it takes more effort to write relocatable code. It takes more effort to write pure code, too, but somehow most of us manage to do it every day. And there's nothing forcing anyone to write relocatable code or relocatable shared libraries. I would just like to believe that people can see the advantages of these features and would want to take advantage of them. <> -- Glenn Weinberg Email: glennw@nsc.nsc.com National Semiconductor Corporation Phone: (408) 721-8102 (My opinions are strictly my own, but you can borrow them if you want.)