Re: KDE a gcc

[Jakub Jelinek <jakub@redhat.com>]

On Mon, Nov 12, 2001 at 03:52:58PM +0100, Jan Hubicka wrote:
> Hi,
> this patch implements idea described in:
> > http://dforce.sh.cvut.cz/~seli/en/linking2/#data_segment
> 
> basically in KDE/QT applications there is lots of pregenerated data that is
> read only, but in PIC compilation it isn't because of dynamic linking.  This
> code is intermixed with other readwrite data then.  With prelinking this is a
> waste, as the pregenereated data is really readonly so it should be put
> together and without it is waste too, as dynamic linker needs to COW much more
> pages.
> 
> This patch adds two new sections. .data.rel is used for read/write data that
> contains relocations (so it will be COWed on startup in case no prelinking is
> done) and .data.rel.ro contains read/only data with relocations that are
> read-only for prelinking and COWed on startup.
> 
> Lubos measured about 60Kb saving on simple QT application requiring about 500Kb
> resources with the prelinking. He estimates savings for KDE application to
> about 200Kb.  I made simple test with sartup time on the c++ library from
> crystal space w/o prelinking and got about 6% savings in startup time too.
> 
> Note that I am not quite sure whether .data.rel / .data.rel.ro are handled as
> .data subsections on all systems.  The patch uses the named sections by
> default, but allows to define new opcodes for that too, hope it is flexible
> enought and will not bring considerable compatibility issues.

As the patch is missing, I cannot comment on it, but only guess.
Is .data.rel for R/W data which need relocations?
I had in mind .data.ro.rel and .data.ro.localrel where the former would be
R/O data which is expected to have dynamic relocation while the latter would
be for R/O data which is expected to have just relative relocations.
E.g. in
extern char foo[];
char * const p[] = { foo };
char * const q[] = { "foo" };
p would go into .data.ro.rel and q into .data.ro.localrel.
For prelinking, the advantage would be that data which would be never
relocated would be put together (there will be just a R_*_RELATIVE reloc
against q and prelinked libs are already relocated to the address they will
be mapped to (unless something gets in the way)), while .data.ro.rel might
be runtime relocated.

	Jakub