From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8585 invoked by alias); 12 Nov 2001 15:10:22 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 8105 invoked from network); 12 Nov 2001 15:08:57 -0000 Received: from unknown (HELO devserv.devel.redhat.com) (199.183.24.200) by sourceware.cygnus.com with SMTP; 12 Nov 2001 15:08:57 -0000 Received: (from jakub@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) id fACF8p204749; Mon, 12 Nov 2001 10:08:51 -0500 Date: Tue, 13 Nov 2001 04:26:00 -0000 From: Jakub Jelinek To: Jan Hubicka Cc: Lubos Lunak , rth@cygnus.com, gcc-patches@gcc.gnu.org, patches@x86-64.org Subject: Re: KDE a gcc Message-ID: <20011112100851.P4087@devserv.devel.redhat.com> Reply-To: Jakub Jelinek References: <200110030715.f937FCT75772@ns.felk.cvut.cz> <200110312108.WAA21661@stoupa.sh.cvut.cz> <20011101145241.E31305@atrey.karlin.mff.cuni.cz> <200111011733.SAA25987@stoupa.sh.cvut.cz> <20011112155258.H8833@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011112155258.H8833@atrey.karlin.mff.cuni.cz>; from jh@suse.cz on Mon, Nov 12, 2001 at 03:52:58PM +0100 X-SW-Source: 2001-11.fuckfuckfuck/txt/msg00049.txt Message-ID: <20011113042600.QOrn78Iz5PLQ5KsZDNXfy1fx_stRGMhfGiUuBMpPk1Y@z> 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