NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/unix/aix/8131

Text File | 1992-07-23 | 3.5 KB | 73 lines

Newsgroups: comp.unix.aix
Path: sparky!uunet!newsgate.watson.ibm.com!yktnews!admin!yktnews!prener
From: [e-mail] (Dan Prener)
Subject: Re: AIXv3 shared-library binding anomolies
Sender: [e-mail] (NNTP News Poster)
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 23 Jul 92 23:50:23 GMT
Date: Fri, 24 Jul 1992 07:55:41 GMT
Distribution: comp
Disclaimer: This posting represents the poster's views, not necessarily those of IBM
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Nntp-Posting-Host: prener.watson.ibm.com
Organization: IBM T.J. Watson Research Center, Hawthorne, New York
Lines: 55

My apologies for the depth of nesting in the following citations.  I was not
clear enough in my previous posting.

In article <[e-mail]> [e-mail] (Mike Heath) writes:

>In article <[e-mail]> [e-mail] (Dan Prener) writes:
>>In article <[e-mail]> [e-mail] (Marc Kwiatkowski {Host Software-AIX}) writes:
>>>There are two separate issues here.  First, the shared libc binds
>>>local function calls at load time.
>>
>>Actually, it binds them at link time.  Is that what you mean by "load time"?
>>I tend to think of load time as the time "exec" loads the program.

>They are bound at link time, but the relocation information is retained.
>They could be rebound at load-time, but rebinding to an out-of-module
>routine would further complicate the program loader.  Also, how would
>the memory segment be shared among multiple processes?

The calls from one routine in a shared library to another routine in
a shared library can not be rebound at load time, since the only field
that is relocated is the (relative) displacement in the branch-and-link
instruction, and the instructions in shared library routines are shared
by all processes.  Therefore you cannot change the target of the branch
for one process without changing it for all processes.

>>... Given the
>>lack of indirection in the current scheme, there is no way the bindings
>>can be changed at run time.

>I don't see why not, but there would probably be a big price to pay.

For the reason given above: without indirection, through data rather
than through program text, any change would apply to all processes.

>>>I am a little skeptical about the claims of improved performance by
>>>statically binding inter-library calls to exported functions.  What
>>>percentage of all function calls within libc.a are calls to libc.a entry
>>>points?
>>
>>The figure would depend on the application.  Statically, I think the
>>vast majority are.

>Either I've misunderstood the question or the answer.  I think the question
>was refering to the shared part of the C library.  That shouldn't change
>with the application.  Sadly, the answer is more than you would have
>thought.  I count over 1000 different routines referenced within itself.
>Of course, damn near everything is exported.  The number of references
>for each routine is unimportant.

The question was referring to calls from routines in the shared
library.  The reason the performance would depend upon the application
is that what matters is the dynamic count, rather than the static
count, of how many such calls are to exported routines.
--
                                   Dan Prener ([e-mail])