This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Large, modular C++ application performance ...
- From: "H. J. Lu" <hjl at lucon dot org>
- To: michael meeks <michael dot meeks at novell dot com>
- 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, 2 Aug 2005 06:57:22 -0700
- 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> <1122976741.25656.54.camel@linux.site>
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.