Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!samsung!know!ladcgw.ladc.bull.com!hermes.ladc.bull.com!fmayhar From: fmayhar@hermes.ladc.bull.com (Frank Mayhar) Newsgroups: comp.unix.internals Subject: Re: Fundamental defect of the concept of shared libraries Keywords: ISC i386 shared libraries Message-ID: <1991May20.231753.8694@ladc.bull.com> Date: 20 May 91 23:17:53 GMT References: <162@titccy.cc.titech.ac.jp> <7690@auspex.auspex.com> <169@titccy.cc.titech.ac.jp> <7762@auspex.auspex.com> <184@titccy.cc.titech.ac.jp> <1991May16.002617.15386@ladc.bull.com> <197@titccy.cc.titech.ac.jp> Sender: usenet@ladc.bull.com (Usenet News) Reply-To: fmayhar@hermes.ladc.bull.com Organization: Bull HN Information Systems Los Angeles Development Center Lines: 102 Nntp-Posting-Host: hermes.ladc.bull.com In article <197@titccy.cc.titech.ac.jp>, mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: -> In article <1991May16.002617.15386@ladc.bull.com> I write: -> >There may actually not be any "right" implementations extant at the -> >moment (this is debatable), but that's not the point. -> Without any fact, your claim is nothing. Let's see _you_ start including "facts" in your postings, then. So far all I've seen is supposition and unsupported assertions. -> Effeciency is only one aspect of the problem. Not true. Regardless of the complexity of the implementation, the only real tradeoff is between efficiency and utility. See my previous posts regarding this. -> To share libraries, they should be: -> 1) coded position independently (PIC) -> or -> 2) assigne static virtual address Granted, more or less. -> If we take 1), the hardware architecture must support PC relative jump, -> of course. Moreover, to access library private data, it must also -> address data PC relative. Not necessarily. While it may well need PC-relative transfers, data addressing may use an different mechanism (probably also register-relative, but almost certainly not PC-relative). -> Aside from effeciency, not all architechture support this. Examples? Certainly the 680x0 and the 80x86 support this, as well as most mainframe architectures. I expect that almost any architecture would support this. I mean, what's the difference between PC-relative addressing and any other kind of register-relative addressing? And, as has already been stated, PC-relative jumps aren't essential; other forms of indirect transfers work as well. -> Note that, library private data is inevitable to support calls between -> libraries, position independently. Not inevitable. It depends on the implementation; I can certainly imagine an implementation that supports inter-library calls via use of automatic storage ("stack" space). While technically this is "library private data," it doesn't have the implementation complexities that static storage does. -> Even worse, with some architechture, it is impossible to map several virtual -> addresses to a physical address. Virtually tagged cache and inverted -> page tables are notable examples. Perhaps these architectures aren't suitable for shared libraries. And, as Barry Margolin said, if this is the case, _any_ kind of text sharing is dead. IMHO, though, the concept of virtual memory implies the ability to map a physical address to several virtual addresses. Show me one that doesn't allow this, and I'll show you one that is almost useless for modern computing purposes. -> If we take 2), even if you have enough address space to map all libraries -> (32 bits is obviously not enough, I even think 48 bits is not), it will -> be nightmare to maintain consictency. Different libraries must -> have different addresses, of course, which is already non-trivial. How is 32 bits "obviously" not enough? Four gigabytes of address space isn't enough? How big _are_ your programs, anyway? I agree that solving such problems are nontrivial, but that doesn't mean that they aren't worthwhile. -> Moreover, compatible libraries must have the same address, whose scheme -> will be very complex, even though it exists. I don't understand this. Your English is somewhat mangled. Care to explain? -> Even worse, if a program is linked with libraries A.0 and B.0 and the -> other program is linked with libraries A.0 and B.1 (an upgraded version -> of B.0) and a function in A.0 calls a funtion in B.*, it can't. Why not? Seems to me that it would depend on the context of the call: if the call is happening in the first program, the call would be to B.0; if in the second, the call would be to B.1. Regardless, this is an implementation issue. Likely nontrivial, but solvable. -> As -> a workaround, we can have two versoins of A.0: A.0.B.0 and A.0.B.1. -> Thus, with the increase of number of kind of libraries, the number of -> libraries and required storage grows exponentially. The above scheme would avoid this problem. -> I hope you can now understand how complex the shared library is. Oh, I quite understand that shared library _implementations_ are complex. I hope that you can now understand that shared libraries are often _useful_, regardless of the complexity of the implementation. -> The fundamental solution is, of course, not to have shared libraries. The fundamental solution is, of course, not to engage in pointless religious arguments with dogmatic individuals who are closed to any ideas not their own. -- Frank Mayhar fmayhar@hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar) Bull HN Information Systems Inc. Los Angeles Development Center 5250 W. Century Blvd., LA, CA 90045 Phone: (213) 216-6241