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

[Michael Matz <matz at kde dot org>]

Hi,

On Wed, 30 May 2001, Joe Buck wrote:
>
> So the next thing to try (Michael Matz, or another interested party) is
> to see if you can make any private data members effectively a secret
> of the library at object code level.  This means that any inline
> functions that access those objects should be moved to a .cxx file
> that belongs to the same shared library as the definition of the object.

Yep, like I already wrote, simply don't allow inline accessors.  OK, I've
done that for kdecore and konsole as a test-program (there it's only the
KApplication::KApp variable, the static instance of the application
object, which makes such problems and from which I constructed my last
example).  Still no go.  The problem now seems to be more involved (and it
seems to be different problems), I couldn't make a small example (I'll try
further), so I give the circumstances:

one problem is our template KStaticDeleter, which serves as a type-safe
delete mechanism for objects which are allocated in such a way:
void f() {
  static Object* o = 0;
  if (!o) o = new Object;
  ...
}

Without further means o would be a program-exit memleak, so we have a
template (for type-safety) which collects all such objects in a list,
which then is cleaned at program exit.  It's used similar to this:
static Deleter<Object> del;
void f() {
  static Object *o = 0;
  if (!o) o = del.setObject(new Object);
  ...
}

We make use of this template in all libraries, and konsole segfaults as
soon as kdecore is -Bsymbolic (kdecore is the place of
deleteStaticDeleter, which traverses the appropriate list and deletes all
these objects).  This segfault doesn't go away when other libraries are
either -Bsymbolic or not, and also not, when everything (also the program
konsole) is -fPIC.  OK, I simply disabled the routine to see, if there are
other problems lurking, and as long as libkdeui is _not_ -Bsymbolic at
least konsole seems to work.  I haven't measured any timing thoroughly,
but the overall effect is, that 10 runs of "konsole -e exit" take 0.7
seconds less (lib{qt,DCOP,kdeui,kssl} where not -Bsymbolic, all other
relevant KDE libs were).

I tried to come up with a reduced example implemented along these lines,
but it worked.

Another data-point, that shared-data seems not the above problem (besides,
that -fPIC for the program didn't help), is, that konsole (without -fPIC)
doesn't show any R_386_COPY relocations for symbols in kdecore (at test
time the only -Bsymbolic lib), _besides_ type info nodes and vtables.
The latter leads me to another problem:

When kdeui is also -Bsymbolic (and the staticdeleter routine is
deactivated), I have a funny crash in some dynamic_cast connected
function:
#0  0x40db346d in __class_type_info::dcast (this=0x8087394,
    desired=@0x403ab378,
    is_public=1, objptr=0x810c288, sub=0x40c3b788, subptr=0x810c288)
    from /usr/lib/libfam.so.0
#1  0x40db3c06 in __dynamic_cast (from=0x807d7d0 <Konsole type_info
    function>,
    to=0x40373410 <KActionCollection type_info function>,
    require_public=1,
    address=0x810c288, sub=0x805684c <QObject type_info function>,
    subptr=0x810c288) from /usr/lib/libfam.so.0
#2  0x402f5d55 in KAction::parentCollection () from
    /opt/kde2/lib/libkdeui.so.3

Besides the fact, that the dynamic_cast functions come from libfam (it's
the static libgcc, or libstdc++, as libfam is partly C++, which has lead
to more problems in the past), which is not a problem, I can only guess,
that this crash result from the non-sharing of RTTI and virtual-table
information, although it would be shared without -Bsymbolic.  I believe,
that those info is read-only, so, what could be the cause of any
observable differences in RTTI with -Bsymbolic?  (I can only imagine
pointer comparings to the RTTI nodes itself, which differ in-library and
out-of-library with -Bymbolic).  I haven't tried yet to come up with a
smaller example demonstrating this.

The last thing seem to be a severe problem, and unavoidable.  Even if I
would eliminate all inline accessors to eliminate shared data, there are
still RTTI and vtable nodes, over which I have no control, and if that is
really the cause of the second crash above, -Bsymbolic as it is now seems
not to be applicable.  Hmm.  I want a -Bsymbolic_for_func. ;)


Ciao,
Michael.