This is the mail archive of the
mailing list for the GCC project.
Re: [I don't think it's off-topic at all] Linking speed for C++
- To: rth at redhat dot com (Richard Henderson)
- Subject: Re: [I don't think it's off-topic at all] Linking speed for C++
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Thu, 10 May 2001 16:42:34 -0700 (PDT)
- Cc: jbuck at synopsys dot COM (Joe Buck), aj at suse dot de (Andreas Jaeger), biswapesh dot chattopadhyay at bt dot com, gcc at gcc dot gnu dot org, bastian at suse dot com
> > The vtable_pic attribute may be applied to a base class (that is, a class
> > that is not derived from another class). If present, the vtable is
> > generated in offset form (function address minus vtable address);
Richard H. writes:
> Seems ok.
> > The vtable_stubs attribute may be applied to a derived class,
> > provided that some base class has the vtable_pic attribute. This
> > attribute is intended for use when the definitions of the member
> > functions of the derived class are in a different dso than the
> > functions of the base class.
> I suspect that this will be hard for people to use in practice.
I don't think it's so bad. Let's take an oversimplified example,
where we have -lqt (the QT library), -lkdecore (the core of KDE),
and -lkdeui (higher-level KDE stuff). Classes in -lqt use vtable_pic.
For any class whose implementation is in kdecore that is derived
from a class in -lqt, use vtable_stubs. Likewise for any class in
-lkdeui that is derived from a class in one of the other libraries.
An alternative would be to unify the two attributes with something like
vtable_dso("name"), where you give the name of the dso you want the class
to land in, as a string. The only purpose of the argument is that if the
derived class's dso name differs from that of the base class, stubs are
generated. So in the above example, we might write the attribute as
vtable_dso("qt") or vtable_dso("kdecore"). The attribute is inherited
from base classes unless overridden.
> > Exception handling is also non-PIC; sorry, I don't know enough about
> > the current implementation to have any suggestions for reducing the
> > number of relocations.
> This is being addressed in the new eh implementation.