From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17556 invoked by alias); 2 Aug 2005 13:57:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 17509 invoked by uid 22791); 2 Aug 2005 13:57:26 -0000 Received: from smtp102.sbc.mail.mud.yahoo.com (HELO smtp102.sbc.mail.mud.yahoo.com) (68.142.198.201) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Tue, 02 Aug 2005 13:57:26 +0000 Received: (qmail 45773 invoked from network); 2 Aug 2005 13:57:24 -0000 Received: from unknown (HELO lucon.org) (hjjean@sbcglobal.net@69.232.224.217 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 2 Aug 2005 13:57:24 -0000 Received: by lucon.org (Postfix, from userid 1000) id A657364552; Tue, 2 Aug 2005 06:57:22 -0700 (PDT) Date: Tue, 02 Aug 2005 13:57:00 -0000 From: "H. J. Lu" To: michael meeks Cc: Martin Hollmichel - Sun Germany - ham02 - Hamburg , Giovanni Bajo , gcc@gcc.gnu.org Subject: Re: Large, modular C++ application performance ... Message-ID: <20050802135722.GA23692@lucon.org> References: <1122666555.19624.25.camel@linux.site> <019e01c5950b$a7ddff90$bf03030a@trilan> <1122889126.19623.105.camel@linux.site> <20050801155517.GA5095@lucon.org> <1122976741.25656.54.camel@linux.site> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1122976741.25656.54.camel@linux.site> User-Agent: Mutt/1.4.1i X-SW-Source: 2005-08/txt/msg00056.txt.bz2 On Tue, Aug 02, 2005 at 10:59:01AM +0100, michael meeks wrote: > Hi H.J., > > > Why can't you you do it with ELF using a linker map? Libstdc++.so is > > built with a linker map. Any C++ shared library should use one if the > > startup time is a big concern. Of coursee, if gcc can generate a list > > of symbols suitable for linker map, which needs to be exported, it will > > be very helpful. I don't think it will be too hard to implement. > > So - the thing about linker maps (cf. the ldump4 tool) is that they > tend to be hard to maintain, not portable across platforms, a source of > grief and problems etc. ;-) [ we have several strata of old, now defunct > link maps lying around from previous investments of effort that > subsequently became useless ]. Maitaining a C++ linker map isn't easy. I think gcc should help out here. > > As I recall, I saw a suggestion (from you I think), for a new > visibility attribute 'export' or somesuch, that would resolve names > internally to the library, while still exporting the symbols. I sugggested the "export" visibility to export a symbol from an executable, even if it wasn't used by any DSOs. > > That would suit our needs beautifully - if, when used to annotate a > class, it would allow the various typeinfo / vague-linkage pieces > through as 'default'. Is it a realistic suggestion ? / if so, am happy > to knock up a patch. > > [ and of course, this is only 1/2 the problem - the other half isn't > much helped by visibility markup as previously discussed ;-] > Why not? If you know a symbol in DSO won't be overridden by others, you can resolve it locally via a linker map. H.J.