Re: question regarding prelinking (was: (inc. note from dpkg developers) (was:Bug#XXXXXX: (far too many packages) needs rebuilt for prelinking))
On Sun, Jan 19, 2003 at 04:17:22PM +0100, Emile van Bergen wrote:
> Hi,
>
> On Sun, Jan 19, 2003 at 02:48:16PM +0000, Tom Badran wrote:
>
> > On Sunday 19 Jan 2003 2:00 pm, Emile van Bergen wrote:
> >
> > > And each time a page of code in a library contains instructions that
> > > must be fixed up at load time for an application, that page cannot be
> > > shared among applications. A waste of memory.
> >
> > This i believe is incorrect, one a library is in memory, all binaries
> > that are loaded that use it have their symbols mapped to the library
> > in memory.
>
> Yes, but I mean something different.
>
> To clarify: suppose there's an application X and an application Y, both
> dependending on library L, which in turn depends on library M.
>
> Now, each application maps L at a different address. This doesn't
> require instructions in L to be modified (which would prevent sharing
> pages), because .so libraries contain position independent code. No
> wastage here yet.
>
> But then, notice that L uses library M. And suppose that in process X, M
> got mapped at a different address than where M got mapped in process Y.
> I see no reason for that to be impossible or unlikely, if applications X
> and Y each map a different set of libraries before mapping L.
>
> That would mean that all instructions in L that refer to functions or
> data in library M, will have to be fixed up using different addresses,
> for the applications X and Y. That means that the pages of L containing
> those instructions, can suddenly no longer be shared among X and Y.
>
> Please correct me if I'm wrong here, because if I'm right, it would mean
> that using lots of interdependent shared libraries is not only slow, it
> also needs extra per-process private pages, which means wasting
> (potentially lots of) memory.
In addition to what others have said, prelinking generally specifies a
prefered load address for the library; choosing these addresses is why
prelink is ideally run on a complete system. That avoids the whole
problems.
And yes, this sort of fixup is supposed to be contained to the GOT.
That's part of what being PIC means.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
Reply to: