| Author |
AIX shared libraries: early or late binding?
|
|
| Dan Stromberg 2005-07-18, 5:53 pm |
|
I did a bit of googling but didn't find anything relevant.
When using shared libraries on AIX, are symbols required for the program
to be fully functional all bound at load time, or are they bound only
after something actually calls a given function?
Thanks!
| |
| Norman Black 2005-07-18, 5:53 pm |
| "Dan Stromberg" <strombrg@dcs.nac.uci.edu> wrote in message
news:pan.2005.07.18.22.19.15.679848@dcs.nac.uci.edu...
>
> I did a bit of googling but didn't find anything relevant.
>
> When using shared libraries on AIX, are symbols required for the program
> to be fully functional all bound at load time, or are they bound only
> after something actually calls a given function?
I cannot claim to be an expert but it appears to be load time only. I have
written linkers for ELF (Linux, Solaris) and recently XCOFF (Aix) and the
stub code that transfers control on a call to a shared object on AIX does
not seem to support binding when called as the ELF stub code does. On ELF
the stub code (they call it plt) branches to a call to the dynamic linker
and it then patches the stub code to go directly to the procedure. On AIX
the stub code (they call it glink) transfers control directly to the
procedure.
Norman
Saperion Inc.
| |
| Kamal R. Prasad 2005-07-19, 2:48 am |
|
Dan Stromberg wrote:
> I did a bit of googling but didn't find anything relevant.
>
> When using shared libraries on AIX, are symbols required for the program
> to be fully functional all bound at load time, or are they bound only
> after something actually calls a given function?
>
> Thanks!
The frist one you described is load-time binding and can be enabled by
defining LD_BIND_NOW environment variable.
The second is run-time binding and happens when the environment
variable LD_BIN_NOW is either null or undefined.
Have a look at IBM's website:-
http://publibn.boulder.ibm.com/doc_...ary_dynamic.htm
regards
-kamal
-----------------------
UNIX systems consultant
http://www.kamalprasad.com
| |
| Uli Link 2005-07-19, 2:48 am |
| Dan Stromberg schrieb:
>
> When using shared libraries on AIX, are symbols required for the program
> to be fully functional all bound at load time, or are they bound only
> after something actually calls a given function?
>
Both is possible.
the traditional default is load time binding. AIX 4.2.1 introduced
run-time dynamic linking, something that existed as an add-on for 3.2.5
and 4.1 too.
Starting with 4.2.1 ld knows the option -brtl which enables run-time
linking and shared libraries using *.so extension.
An example how shared libraries are build is configuring/compiling Perl.
--
Uli
| |
| Kamal R. Prasad 2005-07-20, 7:53 am |
|
Norman Black wrote:
> "Dan Stromberg" <strombrg@dcs.nac.uci.edu> wrote in message
> news:pan.2005.07.18.22.19.15.679848@dcs.nac.uci.edu...
>
> I cannot claim to be an expert but it appears to be load time only. I have
> written linkers for ELF (Linux, Solaris) and recently XCOFF (Aix) and the
> stub code that transfers control on a call to a shared object on AIX does
> not seem to support binding when called as the ELF stub code does. On ELF
> the stub code (they call it plt) branches to a call to the dynamic linker
> and it then patches the stub code to go directly to the procedure. On AIX
> the stub code (they call it glink) transfers control directly to the
> procedure.
>
No -there is a plt in AIX too which the linker creates at load time.
There is a read-only area in the binary called .interp which points to
the read0-write area (plt). The plt contains function name and the
corresponding address which is left blank. When the function call takes
place, it transfers control to the stub that fills up the plt -so that
subsequent calls will refer to that address. If the LD_BIND_NOW
variable is set, then the linker simulates a call to all of the
functions which then fills up the plt. But the calling mechanism does
go through a stub.
BTW -do you have a clue as to why there are dummy frames created when
calling a syscall?
regards
-kamal
------------------------
http://www.kamalprasad.com/
> Norman
> Saperion Inc.
| |
| Norman Black 2005-07-20, 5:57 pm |
|
"Kamal R. Prasad" <kamalp@acm.org> wrote in message
news:1121752912.891091.4010@g43g2000cwa.googlegroups.com...
>
>
> Have a look at IBM's website:-
> http://publibn.boulder.ibm.com/doc_...ary_dynamic.htm
>
> regards
> -kamal
This is quite wrong. This is referencing ELF. AIX on Power systems uses
XCOFF. Completely different mechanisms in XCOFF.
Norman
Saperion Inc.
| |
| Norman Black 2005-07-20, 5:57 pm |
|
"Kamal R. Prasad" <kamalp@acm.org> wrote in message
news:1121854497.734002.65280@o13g2000cwo.googlegroups.com...
>
>
> No -there is a plt in AIX too which the linker creates at load time.
> There is a read-only area in the binary called .interp which points to
> the read0-write area (plt). The plt contains function name and the
> corresponding address which is left blank. When the function call takes
> place, it transfers control to the stub that fills up the plt -so that
> subsequent calls will refer to that address. If the LD_BIND_NOW
> variable is set, then the linker simulates a call to all of the
> functions which then fills up the plt. But the calling mechanism does
> go through a stub.
I have never seen a .interp section in an XCOFF file, nor have I seen such a
thing referenced in XCOFF documentation. This smells like ELF which does
have a .interp section.
The runtime linker would have to make the TOC entry for the function being
called through the glink code (XCOFF style) to call this plt code you have
described and then once linked the TOC entry the glink uses can be changed
so the glink code calls the function directly. Just one thing, the TOC entry
the glink code uses has a fixup to the descriptor of the actual function.
> BTW -do you have a clue as to why there are dummy frames created when
> calling a syscall?
Sorry, can't help you here.
Norman
Saperion Inc.
| |
| Andrew Gabriel 2005-07-20, 5:57 pm |
| In article <1121854497.734002.65280@o13g2000cwo.googlegroups.com>,
"Kamal R. Prasad" <kamalp@acm.org> writes:
> BTW -do you have a clue as to why there are dummy frames created when
> calling a syscall?
I seem to recall finding dummy stackframes in AIX code in the
middle of functions, usually where the code had a set of nested
{}'s with some declarations inside them, which seemed to get a
new stackframe for storage. I'm going back 10 years now though,
when I was trying to write a function to dump out the stacktrace
on various different unix systems (which I never got to work on
AIX as a result of the extra stackframes).
--
Andrew Gabriel
| |
| Kamal R. Prasad 2005-07-20, 5:57 pm |
|
Andrew Gabriel wrote:
> In article <1121854497.734002.65280@o13g2000cwo.googlegroups.com>,
> "Kamal R. Prasad" <kamalp@acm.org> writes:
>
> I seem to recall finding dummy stackframes in AIX code in the
> middle of functions, usually where the code had a set of nested
> {}'s with some declarations inside them, which seemed to get a
> new stackframe for storage. I'm going back 10 years now though,
> when I was trying to write a function to dump out the stacktrace
> on various different unix systems (which I never got to work on
> AIX as a result of the extra stackframes).
>
It looks like there are some optimization flags in xlc which can impact
the stack frame geenration. The pre-compiled binaries from IBM produce
a stack which is not consistent with what I can see from kdb/procstack.
Does the process save the stackframes somewhere else too -that the avg
joe cannot find it, but kdb can?
regards
-kamal
> --
> Andrew Gabriel
|
|
|
|