This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: more prelink


On Sun, Sep 29, 2002 at 11:50:38PM +0200, Jakub Jelinek wrote:
> On Sun, Sep 29, 2002 at 05:43:12PM -0400, Daniel Jacobowitz wrote:
> > On Sun, Sep 29, 2002 at 11:30:01PM +0200, Jakub Jelinek wrote:
> > > On Fri, Sep 27, 2002 at 11:39:06PM -0400, Jack Howarth wrote:
> > > > Jakub,
> > > >    I think I have stumbled over another issue with prelink that
> > > > could be problematic unless addressed. Currently the glibc srpms
> > > > are using a postinst script to prelink libc.so.6 with the
> > > > --reloc-only flag so it is relinked to the specified base address.
> > > > If I do that on entropy with...
> > > > 
> > > > /usr/sbin/prelink --reloc-only=0x40000 /lib/libc-2.2.94.so
> > > 
> > > I'm terribly sorry to say, but now that I think about it, --reloc-only
> > > for libc.so makes no sense on ppc/x86-64/sparc* etc. Sorry for
> > > forgotting about this.
> > > It speeds things up on REL or ELF_MACHINE_REL_RELATIVE arches only.
> > > ELF_MACHINE_REL_RELATIVE are those where R_*_RELATIVE relocs have the
> > > addend in *r_offset. ppc/x86-64/sparc* usually have zero there.
> > > Even if I changed back binutils to put addend to both r_addend and *r_offset
> > > on ppc, ELF_MACHINE_REL_RELATIVE could not be defined because there are
> > > already many -z combreloc binaries and libraries out there I think
> > > and they'd suddenly fail in weird ways.
> > > R_*_RELATIVE relocs can be skipped on the other
> > > arches (ppc, x86-64, sparc*, ...) if the library is prelinked, not
> > > just prelink -r'ed. Then it guarantees *r_offset has the proper value.
> > 
> > How big is the performance difference?  If it's worthwhile, we could
> > add (say) a dynamic tag which guarantees us that the binary has this
> > property.
> 
> Such dynamic tag already exists, DT_GNU_PRELINKED.
> How big is the performance difference depends on a bunch of things,
> like how many RELATIVE relocs there are and how many pages
> normally read-only pages are there with just RELATIVE relocs against
> it and no other ones.
> So running prelink (without -r) will make that happen.

>From what you say above, then, can't we check the presence of
DT_GNU_PRELINKED and if it is present, use this optimization even on
Rela architectures?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]