This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

PATCH: Add export to linker map (Re: Large, modular C++ application performance ...)

On Tue, Aug 02, 2005 at 05:14:36PM +0100, michael meeks wrote:
> On Tue, 2005-08-02 at 06:57 -0700, H. J. Lu wrote:
> > Maitaining a C++ linker map isn't easy. I think gcc should help out
> > here.
> 	What do you suggest ? - something separate from the visibility markup ?
> perhaps what I'm suggesting is some horribly mis-use of that. Clearly
> adding a new visibility attribute that would bind that symbol
> internally, yet export it would be a simple approach; did you have a
> better idea ? and/or suggestions for a name ? - or is this a total
> non-starter for some other reason ?

The problem is there is no bit in ELF symbol table to support new
attribute. However, we do have linker map. This patch adds the new
"export" key word. It can be used to export a symbol even if it is
hidden or it is defined in executable and not referenced by any DSOs.
The difference between "export" and "global" is exported symbol will
be resolved locally.

I think it is possible for gcc to generate linker script automatically.
It knows which symbols have to be defined once, which symbols can
be resolved locally and which symbols should exported. We can even
add new attributes for symbol versions. We don't have to maintain
linker-map.gnu by hand.

> > > 	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.
> 	Sure - the other (more than) 1/2 of the performance problem comes from
> named relocations to symbols external to the DSO.

You only need that if there has to be one and only definition. How many
symbols have to be defined once in a C++ DSO?


Attachment: binutils-version-scope-2.patch
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]