This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [I don't think it's off-topic at all] Linking speed for C++
- To: aj at suse dot de (Andreas Jaeger)
- 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: Wed, 9 May 2001 09:19:59 -0700 (PDT)
- Cc: biswapesh dot chattopadhyay at bt dot com, gcc at gcc dot gnu dot org, bastian at suse dot com
> > Just wondering if this would be useful for GCC developers. This is written
> > by Waldo Bastan, one of the key KDE developers and contains some interesting
> > statistics about the GNU linker, etc.
> >
> > http://www.suse.de/~bastian/Export/linking.txt
>
> It has been discussed already on the libc-alpha list, check the
> archives via http://sources.redhat.com/glibc
To be more direct, go to
http://sources.redhat.com/ml/libc-alpha/2001-05/threads.html
and read the thread entitled "Prelinking of shared libraries"
I don't think that this is off-topic at all. The need for lots of
relocations in C++ code is a consequence of gcc's design (actually,
gcc is just doing what other C++ compilers do, but still ...), so if it isn't
on topic here, what is? Working around the problem is interesting, but
can we attack the problem more directly?
I've been thinking about this and I think it might be worth experimenting
with a modified vtable implementation. I AM NOT PROPOSING TO MODIFY THE ABI.
Rather, users could designate that the modified implementation be used
in specific cases.
The idea would be that an attribute, say pic_vtable, could be added to a
base class. It would specify that the vtable for this class and all
derived classes would use the modified vtable implementation. It would
be an error to attempt multiple inheritance from classes with different
values of this attribute.
If pic_vtable is specified, the function pointers in the virtual function
table would be replaced by (pointer - vtable_address). This means that
they would now be PIC. The penalty is that a virtual function call now
has to do an extra arithmetic operation:
before: assume register 0 has a pointer to the object
register1 <- *(register0) ; get vtable address
register2 <- *(offset + register1) ; get function address
call *register2
after
register1 <- *(register0)
register2 <- *(offset + register1) + register1
call *register2
On the x86 it might be possible to do this without an extra instruction,
since the add can take a memory operand, but I haven't tried it.
Thoughts? Flames?
I haven't dealt with exception handling here, that is also a source of
non-PIC code.