Re: Solaris -z combreloc bug?

["Antti Kerola" <antti dot kerola at insta dot fi>]

> On Thu, Oct 21, 2004 at 11:31:06AM +0300, Antti Kerola wrote:
> > We are experiencing very long application start up times which is due to
the
> > fact that the runtime
> > linker is spending a _lot_ of time binding symbols.
>
> In shared libs or executables?  If shared libs, perhaps you are
> compiling them non-PIC?  Do you have LD_BIND_NOW set in your
> environment?

We are compiling with -fPIC and LD_BIND_NOW is not set. We are experiencing
this while
loading shared libraries.

I looked into this in more detail tonight. We have a class definition in
each object file of the shared
library. These classes typically inherit a complex framework class with lots
of virtual methods.
For example classes A, B and C in the shared library could inherit the same
framework class D.

Looking at a single object file with objdump -r I see a section starting
with RELOCATION RECORDS FOR [.gnu.linkonce.d._CLASSNAME] in each object
file. This is followed by R_SPARC_32 references to all the methods of the
class CLASSNAME. As I told I am not a linker expert, but I presume that this
is the virtual function table of the class CLASSNAME defined in the object.
Anyway I will call these table "virtual function tables" in the explanation
below.

Lets say we have defined 15 classes in 15 objects in a shared library and
all the classes are derived from the same framework class. These 15 classes
typically only override couple of framework methods and inherit the rest.
Therefore in each
object file the  file contains a  "virtual function table" mostly only
having references to the methods of class D.
So I end up having about 15 references to each method of class D. When I
build a shared library from the object, all the other
duplicate function references are collapsed to one single refenrence but
these references in the "virtual function
tables" are not. If I look at the shared library with objdump -R I see each
method of class D as many times
as there are classes inheriting from the class D minus, of course, the
methods which are overriden, but they
are a small minority.

The problem is agravated if we have a framework class using virtual
inheritance. In that case there are several
"virtual function tables" emitted into object file.

The result of all this is that the runtime linker seems to be spending most
of its time binding these same virtual framework
methods again and again. This is the feeling I get anyway by looking at the
output I get with LD_DEBUG environment
variable. The bindings to these "virtual function tables" form the vast
majority of all the bindings.

Is this all normal? Should we use some linker switch?  Or is there  a way to
prebind all these references so that
the binding are performed before runtime? In production environment we are
using shared libraries mostly
to save disk space. It would not be a bid deal, if we could not link
dynamically to a different library.

Any help will be highly appreciated.

Antti Kerola



----- Original Message -----
From: "Alan Modra" <amodra@bigpond.net.au>
To: "Antti Kerola" <antti.kerola@insta.fi>
Cc: <binutils@sources.redhat.com>; "Rantala Jukka-Pekka"
<Jukka-Pekka.Rantala@insta.fi>; "Kaitajarvi Sami"
<Sami.Kaitajarvi@insta.fi>; "Koski Aapo" <Aapo.Koski@insta.fi>
Sent: Thursday, October 21, 2004 2:47 PM
Subject: Re: Solaris -z combreloc bug?


> On Thu, Oct 21, 2004 at 11:31:06AM +0300, Antti Kerola wrote:
> > We are experiencing very long application start up times which is due to
the
> > fact that the runtime
> > linker is spending a _lot_ of time binding symbols.
>
> In shared libs or executables?  If shared libs, perhaps you are
> compiling them non-PIC?  Do you have LD_BIND_NOW set in your
> environment?
>
> --
> Alan Modra
> IBM OzLabs - Linux Technology Centre
>