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 Tue, 2005-07-05 at 20:40 +0200, Jakub Jelinek wrote:
> > 	OK - so, my binutils change does slightly better without the various
> > complexities, latencies, limitations etc. of pre-linking :-)
> 
> Not sure what complexities/latencies/limitations you are talking about.

	One doesn't want to argue ;-) however, the concept of re-pre-linking
~everything on the system when you update a fundamental library doens't
appeal to me; in particular it's rather less useful than other symbol
driven reloc reduction strategies for the up-stream guys, since OO.o
ships on old & new systems without a working prelink setup - and (I
guess) shipping a self-contained pre-link setup would not be that easy.

> Anyway, when I cooked up a quick hack (don't really want to build OOo
> myself, so all I did was:

	Interesting - of course; I can try to reproduce this & we can certainly
re-work the soffice.bin build so it links lots more of the large
libraries against the main binary [ I'll look at that in a bit ]; but -
really having a simple & self-standing partial solution is more
attractive to me than pre-linking - and will of course help where
pre-linking cannot easily reach - the subsequent dlopening tens of
random components etc.

> And how that matters if there is a single binary or multiple binaries?

	I guess the point is that there can only be 1 binary running
concurrently; we already have an IPC/factory thing anyhow.

> Sure, that would be certainly useful.  I even tried that several years ago,
> but at that point such OOo did not start at all, because many places
> in OOo didn't care about ODR at all, the same name was used for completely
> different functions/classes.

	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 ?

> > 	What did you think of the patch ? ;-)
> 
> There is nothing special about weak symbols in this regard, they might
> actually be replaced with strong symbols now that gcc/linker has COMDAT
> support.

	This is confusing to me - this new gcc/linker support is implemented in
some new development branch ? I googled/read the 'Vague Linkage' page
but got none the wiser; is there a good write-up of COMDAT - how it
helps, how to use this instead of weak symbols ? and/or some code
pointers & I can poke myself. I guess what I'm missing is some idea of
what is possible & not in binutils wrt. releasing. ie. If I made a patch
for '-Binternalize-globals' or somesuch & it was suitably clean etc.
would it be possible to get that into a binutils release ? or will the
next binutils release be concurrent with the adoption of COMDAT & hence
it's pointless & I should just wait a year while distros re/spin with an
improved tool-chain or ... ?

>   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 ? :-)

>   ELF has symbol visibility that is designed for these kind of
> per-symbol decisions.

	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();

	but - that's a staggeringly gigantic & hard to create & maintain change
to millions of lines of source :-) [ that achieves the same effect as
this ~10 line ld patch ;-]

	Of course - if there is some good way I'm unaware of to achieve the
same thing without this patch - I'm eager to find it out. I guess
another solution would be to wrap 'ld' with something that ran objdump
on all of it's non-dynamic-library input files; grokked the weak
symbols, generated a map list - that could override the existing symbol
visibility (as per H.J.Lu's patch) & feed that into the real ld. - That
seems like the grossest of ugly hacks though ;-)

	Anyhow - sorry for all the clueless questions & thanks for your kind
patience.

	Regards,

		Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot


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