Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!kddlab!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.internals
Subject: Re: Fundamental defect of the concept of shared libraries
Keywords: ISC i386 shared libraries
Message-ID: <276@titccy.cc.titech.ac.jp>
Date: 3 Jun 91 02:15:37 GMT
References: <8054@auspex.auspex.com> <8057@auspex.auspex.com> <265@titccy.cc.titech.ac.jp> <8144@auspex.auspex.com>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 38

In article <8144@auspex.auspex.com>
	guy@auspex.auspex.com (Guy Harris) writes:

>You cited B news as an
>example of a place where inlining is a win; that particular example
>doesn't require unshared libraries to get that win.

Don't distort what I said.

See <246@titccy.cc.titech.ac.jp>:

:Yes, of course. Bnews is the real example showing significance of call
:overhead.

I cited B news as the real example showing significance of call overhead.

>There are two separate issues here, which you're mixing together:
>
>1) the issue of code that will run regardless of what its virtual
>   address is, and that doesn't have to be modified to run at a
>   different address;
>
>2) the issue of mapping the same physical page into different virtual
>   addresses within different processes.

I am not mixing them. Both issues have nothing to do with the current
discussion now.

>I
>sincerely *hope* nobody was claiming that the fact that you couldn't was
>at *all* a major obstacle to implementing position-independent shareable
>code objects!

What you don't and I didn't understand is position-independent code is
not necessary for shared libraries. Roughly-position-independent code
is enough.

							Masataka Ohta