From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23877 invoked by alias); 2 Aug 2005 09:59:26 -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 23868 invoked by uid 22791); 2 Aug 2005 09:59:22 -0000 Received: from public.id2-vpn.continvity.gns.novell.com (HELO gwia-smtp.id2.novell.com) (195.33.99.129) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 02 Aug 2005 09:59:22 +0000 Received: from linux.site (l4-client.id2.novell.com [149.44.117.251]) by gwia-smtp.id2.novell.com; Tue, 02 Aug 2005 10:59:03 +0100 Subject: Re: Large, modular C++ application performance ... From: michael meeks Reply-To: michael.meeks@novell.com To: "H. J. Lu" Cc: Martin Hollmichel - Sun Germany - ham02 - Hamburg , Giovanni Bajo , gcc@gcc.gnu.org In-Reply-To: <20050801155517.GA5095@lucon.org> References: <1122666555.19624.25.camel@linux.site> <019e01c5950b$a7ddff90$bf03030a@trilan> <1122889126.19623.105.camel@linux.site> <20050801155517.GA5095@lucon.org> Content-Type: text/plain Date: Tue, 02 Aug 2005 09:59:00 -0000 Message-Id: <1122976741.25656.54.camel@linux.site> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-08/txt/msg00046.txt.bz2 Hi H.J., On Mon, 2005-08-01 at 08:55 -0700, H. J. Lu wrote: > > -fvisibility is helpful - as the paper says, not as helpful as the old > > -Bsymbolic (or link maps exposing only 3 or so functions) were. However > > - -fvisibility can only help so much - if you have: > > Since you were comparing Windows vs. ELF, doesn't Windows need a file > to define which symbols to export for a shared library ? Apparently so - here is my (fragementary) understanding of that - Martin - please do correct me. OO.o builds the .defs on Win32 with a custom tool called 'ldump4'. That (interestingly) goes groping in some binary file format, reads the symbol table, groks symbols tagged with 'EXPORT:', and builds a .def file. ie. it *looks* like it's automated, and can uses the API marked (__dllexport etc.) where appropriate. > 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 ]. 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. 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 ;-] Thanks, Michael. -- michael.meeks@novell.com <><, Pseudo Engineer, itinerant idiot