This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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]

Re: OO.o / ld / -Bsymbolic patch ...


On Wed, Jul 06, 2005 at 12:53:02PM +0100, michael meeks wrote:
> 	Oh ;-) yes - of course - we could get away with that because of
> high-coverage link-maps previously, in OO.o 2.0 - we have (in theory)
> fixed all of those - any remaining are serious bugs. Of course - we
> define the same 'magic' symbols 'component_getFactory' eg. in every
> component - is that what you're referring to ?

For component_* I think I had some hack in place that allowed the component
DSOs to be loaded immediately and then when trying to load those component
would find the needed functions in the big library, the problem was the
other routines/classes/methods with name clashes.

> >   And it is certainly wrong to change the rules for how -Bsymbolic
> > works, it would need to be completely different switch, but still it
> > is wrong to key that off STB_WEAK.
> 
> 	Sure - clearly breaking -Bsybolic is not an option :-) I'm happy with a
> completely different switch - of course, that'd be necessary for not
> emitting DT_SYMBOLIC. But is it really wrong to key off STB_WEAK ? - the
> man page says of -Bsymbolic - "... bind references to global symbols
> to ..." - presumably since STB_WEAK symbols are being bound (which are
> not global?), there is a missing STB_GLOBAL comparison somewhere ? or am
> I confused wrt. the meaning of global ? :-)

I think that's just your confusion.  weak symbols are also globals, in the
sense that they are symbols exported from the library, as opposed to local
symbols that are not in the dynamic symbol tables.
That's the meaning the -Bsymbolic description uses.

> 	Well - I can of course try to get up-stream OO.o to turn every single
> function & member decl. from:
> 
> 	virtual void doFoo();
> to
> #define PROTECTED __attribute__ ((visibility("protected)))
> ..
> 	virtual PROTECTED void doFoo();

Note that "protected" visibility is something you almost never want to use.
It is actually usually slower than not using it at all (involves usually
two symbol lookups instead of one).  The reason for that is C/C++ pointer
equivalence requirements.  "hidden" is useful and actively used by many
projects.  "protected" visibility that disregards C/C++ pointer equivalence
requirements is used e.g. by glibc, I think Gtk2 etc., though complicated
macros and markups in the source.

	Jakub


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