This is the mail archive of the gcc@gcc.gnu.org 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] | |
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? H.J.
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] |