Path: utzoo!attcan!uunet!super!rminnich From: rminnich@super.ORG (Ronald G Minnich) Newsgroups: comp.arch Subject: Re: Putting libc.a into a segment Message-ID: <27411@metropolis.super.ORG> Date: 12 Jun 90 12:03:32 GMT References: <2286@crdos1.crd.ge.COM> <29972@cup.portal.com> <1990May14.141148.9884@xavax.com> <7754@crdgw1.crd.ge.com> <30016@cup.portal.com> <1990May19.230618.16090@utzoo.uucp> <383@garth.UUCP> <1990Jun2.134157.14516@oracle.com> Sender: news@super.ORG Reply-To: rminnich@metropolis.UUCP (Ronald G Minnich) Organization: Supercomputing Research Center, Bowie, Md. Lines: 38 In article <1990Jun2.134157.14516@oracle.com> csimmons@oracle.com writes: >Ah! I can't pass this one up. Turns out that one of your favorite >machines, the GE 6something (well, one of its descendents), does this >sort of thing. The Dartmouth College Time Sharing system started >putting shared libraries in segments in around 1985 or so. Worked >great. Well, ok, as i think maybe Guy pointed out, if you consider /vmunix as a library, then it is a large text segment that has entry points, and thus falls into this class too. But what about a big chunk of code like libc or libX11? On the DG MV/10000 libc was in Ring 3 (if memory serves ... this was 7 years ago). User processes lived in Ring 7. This was in hardware. And of course B. has had library segments for going on 30 years now. The question I keep wondering: EMT or whatever your favorite trap instruction is provides a way, supported in hardware, of calling a library (/vmunix) with a parameter (for sysent) which allows you to call a function without knowing its address. Hardware support for dynamic binding, sort of. In most Unix implementations I have seen /vmunix is the only place this is used, with the aforementioned DG machine being an interesting exception. Stdio and all that good stuff is called with straight standard jsr instructions. My question is now that Unix is finally catching up with dynamic binding in some implementations do we want architectural support so that e.g. calls to libc.a have the same mechanism as the kernel calls (probably not it is pretty expensive) or a *similar* mechanism that is supported in hardware (e.g. mv10000 call gates, 386 call gates, and so on). To put it another way do any of you out there see any change in architecture to support dynamic libraries or dynamic binding or do we stick with traps and munging all this stuff in software? In the current systems I have seen (e.g. SunOS) i tend to worry a little about undetected (and undetectable) jumps into the middle of a function in libc. How do we know this is not happening now? As far as I can tell, we don't. What happens when we find out that maybe it is? ron -- Grad student, ca 1976: Gosh, the v6 kernel is < 64K! Compare it to that OS/MVS hog at 400K! Grad student, ca 1986: Look at all the good stuff in Gnu Emacs for only 600K!