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++

> > 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.
> > 
> >
> It has been discussed already on the libc-alpha list, check the
> archives via

To be more direct, go to

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

	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.

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