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]

Re: [I don't think it's off-topic at all] Linking speed for C++


On Tue, 29 May 2001, Richard Henderson wrote:
> On Tue, May 29, 2001 at 10:57:39PM +0200, Michael Matz wrote:
> > This is due to lib1's version of init() setting another TheA
> > than the one read from in main().  I don't know why exactly
> > this is happening.
> Welcome to Dynamic Linking 304, in which we discuss the peculiarities
> of data symbols as seen on common 32-bit architectures.

;-)  wonderful, educating, funny.  This is how education should be.  How
about you sitting down every two weeks, and write something equally
interesting and entertaining on a random topic. I at least enjoyed reading
very much. :)

> Exhibit B:
> > The program itself has for TheA the following relocation:
> > 0804970c R_386_COPY        _1A.TheA
> For every data object referenced by the main application, the linker
> allocates space in the application's .bss section (sometimes referred
> to as the .dynbss).

I already wondered why in prog there were symbols _1A.TheA pointing to

> Conclusion: symbol resolution rule changes cannot be made in the
> presense of shared (in the multiple users sense) data.

I have the feeling, that -Bsymbolic should only be applied to functions
(or other things for which indirection already exists), and not to data.

(btw. what's sad is, that TheA wouldn't need to be shared data, after all
it's private (C++-wise), and only accessible through accesors.  Only that
they get inlined is the reason why everything falls apart ;)  Not that I
want to turn of inlining for this)

> There is something else to watch here.  Note that the linker had
> to *reserve* space in the application.  This implies that the size
> of the data is known at link time.  Which implies that that size
> is constant.  Which implies that the size of the data is part of
> the ABI, even if the structure is opaque at the language level.

Nice one.  Another line on my blackboard: "beware shared data".

> Of course, there is another way to avoid these problems that
> hasn't been mentioned yet -- build the application PIC as well.

Well, that would be the only way if -Bsymbolic can't be made to leave data
alone, and to still use -Bsymbolic.  At least the small test-program
worked with -fPIC, but I'm not sure I want to take the penalty in KDE (not
that it matters really much, we anyway have most code (outside of
large applications) PICed).  Hmm.


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