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 06:28:14PM -0400, Jakub Jelinek wrote:
> On Sun, Sep 29, 2002 at 06:24:06PM -0400, Daniel Jacobowitz wrote:
> > > 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?
> 
> glibc does that already:
> # if !defined DO_RELA || defined ELF_MACHINE_REL_RELATIVE
>         /* Rela platforms get the offset from r_addend and this must
>            be copied in the relocation address.  Therefore we can skip
>            the relative relocations only if this is for rel
>            relocations or rela relocations if they are computed as
>            memory_loc += l_addr...  */
>         if (l_addr != 0)
> # else
>         /* ...or we know the object has been prelinked.  */
>         if (l_addr != 0 || ! map->l_info[VALIDX(DT_GNU_PRELINKED)])
> # endif
> 
> The --reloc-only=xyz stuff is just a cheap way how to speed things up
> even when not prelinking.

Right.  What I was suggesting was a second dynamic tag
DT_GNU_PRELINKED_RELOCS so that --reloc-only could be used.  I don't
know if it's worth the effort, though.

-- 
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]