This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Large, modular C++ application performance ...
- From: michael meeks <michael dot meeks at novell dot com>
- To: "H. J. Lu" <hjl at lucon dot org>
- Cc: Martin Hollmichel - Sun Germany - ham02 - Hamburg <martin dot hollmichel at Sun dot COM>, Giovanni Bajo <rasky at develer dot com>, gcc at gcc dot gnu dot org
- Date: Tue, 02 Aug 2005 10:59:01 +0100
- Subject: Re: Large, modular C++ application performance ...
- References: <1122666555.19624.25.camel@linux.site> <019e01c5950b$a7ddff90$bf03030a@trilan> <1122889126.19623.105.camel@linux.site> <20050801155517.GA5095@lucon.org>
- Reply-to: michael dot meeks at novell dot com
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