This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] Support -z combreloc in binutils
- To: Jakub Jelinek <jakub at redhat dot com>
- Subject: Re: [PATCH] Support -z combreloc in binutils
- From: Andreas Jaeger <aj at suse dot de>
- Date: Thu, 16 Aug 2001 08:56:16 +0200
- Cc: binutils at sources dot redhat dot com, drepper at redhat dot com
- References: <20010815173030.K510@sunsite.ms.mff.cuni.cz>
Jakub Jelinek <firstname.lastname@example.org> writes:
> This patch adds support for ld -z combreloc, which instead of creating usual
> zillions of .rel* resp. .rela* sections just creates one big (in addition to
> .rel.plt/.rela.plt or PLT-like rela section) .rel.dyn resp. .rela.dyn
> section with all dynamic relocations.
> This section is sorted if possible by increasing r_offset, with the
> exception that if there are multiple relocs against the same symbol, they
> are grouped together (which allows the dynamic linker to have a single entry
> cache for symbol lookups).
> In addition to this, it sets DT_RELCOUNT resp. DT_RELACOUNT dynamic tag in
> the way Solaris linker uses it (and compatible to the Solaris way, which is
> IMHO broken - R_*_RELATIVE symbols come last, not first), so that if a
> library has l_addr 0, all the R_*_RELATIVE relocs can be skipped for free.
> I tried to implement this so that only minimal changes in elf backends are
> needed (each backend just needs to provide function which categorizes reloc
> types: relative, plt, copy relocs or other relocs).
> Also, it reserves a few entries for use in prelinking, but user can disable
> this (this is necessary for DT_REL*COUNT too, since I don't want to create
> it if no relative relocs are found).
Shouldn't combreloc be the default - at least on glibc platforms?
After changing the dynamic linker to cache the last value used for
relocation, this option would speed up relocations at system start up.
Thanks for a great patch,
SuSE Labs email@example.com