実行時リンクのプログラミングインタフェース

ここまでは、アプリケーションのリンク編集中に指定された依存関係が、プロセスの初期設定中に実行時リンカーによってどのように処理されるかについて説明してきました。このメカニズムに加えて、アプリケーションは、追加オブジェクトと結合することにより、その実行中にアドレススペースを拡張できます。この拡張は、アプリケーションのリンク編集中に指定された依存関係の処理と同じ実行時リンカーのサービスを、アプリケーションが要求できるようにすることで提供されます。

この遅延オブジェクトの結合処理には、いくつかの利点があります。

• アプリケーションの初期設定中ではなく、オブジェクトが要求された時点でオブジェクトを処理することにより、起動時間を大幅に削減できる。実際、ヘルプや情報のデバッギングといったアプリケーションの特定の動作中に、そのサービスが必要とされない場合は、オブジェクトが要求されないことがある

• アプリケーションは、ネットワーキングプロトコルなどの、必要なサービスによって決まる、いくつかの異なるオブジェクト間で選択される

• 実行時にオブジェクトに追加されたプロセスのアドレススペースは、使用後には解放される

以下は、アプリケーションが追加の共有オブジェクトにアクセスするために実行する典型的な手順を示しています。これについては次の項で説明します。

• 共有オブジェクトは、dlopen(3X) を使用して実行中のアプリケーションのアドレススペースに配置され、追加される。この共有オブジェクトが所有する依存関係は、この時点で配置されて追加される

• 追加された共有オブジェクトとその依存関係は、再配置され、これらのオブジェクト内の初期設定セクションが呼び出される

• アプリケーションは、追加されたオブジェクト内のシンボルを、dlsym(3X) を使用して配置する。次に、アプリケーションはデータを参照するか、またはこの新しいシンボルによって定義された関数を呼び出す

• オブジェクトによってアプリケーションが終了したあとで、dlclose(3X) を使用してアドレススペースを解放できる。解放されたオブジェクト内の終了セクションは、この時点で呼び出される

• これらの実行時リンカーのインタフェースルーチンを使用した結果発生したエラー状態は、dlerror(3X) を使用して表示できる

実行時リンカーのサービスは、ヘッダーファイル dlfcn.h 内に定義され、共有オブジェクト libdl.so.1 によってアプリケーションで使用できるようになります。次に例を示します。

$ cc -o prog main.c -ldl

ここでは、ファイル main.c は、ルーチンの dlopen(3X) ファミリのどれでも参照でき、アプリケーション prog は、実行時にこれらのルーチンと結合できます。

追加オブジェクトの読み込み

追加オブジェクトは、dlopen(3X) を使用して、実行プロセスのアドレススペースに追加できます。この関数は、引数としてファイル名と結合モードを入手し、アプリケーションにハンドルを戻します。このハンドルを使用すると、アプリケーションは、dlsym(3X)を使用することによってシンボルを配置できます。

ファイル名が、単純ファイル名で指定されている、つまり名前の中に `/' が組み込まれていない場合、実行時リンカーは一連の規則を使用して、適切なパス名を構築します。`/' が組み込まれたファイル名は、そのまま使用されます。

これらの検索パスの規則は、最初の依存関係の配置に使用された規則と全く同じものです (「実行時リンカーによって検索されるディレクトリ」を参照)。たとえば、ファイル main.c は、以下のようなコードフラグメントが組み込まれている場合、

#include        <stdio.h>
#include        <dlfcn.h>
 
main(int argc, char ** argv)
{
    void *  handle;
    .....
 
    if ((handle = dlopen("foo.so.1", RTLD_LAZY)) == NULL) {
            (void) printf("dlopen: %s¥n", dlerror());
            exit (1);
    }
    .....

共有オブジェクト foo.so.1 を配置するために、実行時リンカーは、プロセスの初期設定時に表示されたLD_LIBRARY_PATH 定義に、リンク編集 prog 中に指定された実行パスを続けて入力し、最後にデフォルトのロケーション /usr/lib を入力して使用します。

ファイル名が次のように指定されている場合、

if ((handle = dlopen("./foo.so.1", RTLD_LAZY)) == NULL) {

実行時リンカーは、プロセスの現在の作業ディレクトリ内でこのファイルだけを検索します。

dlopen(3X) を使用して指定された共有オブジェクトは、そのバージョンのファイル名で参照することをお勧めします (バージョンについての詳細は、「バージョンアップファイル名の管理」を参照)。

必要なオブジェクトが配置されていない場合は、dlopen(3X) によって NULL ハンドルが戻されます。この場合、dlerror(3X) を使用すると、失敗した本当の理由を表示できます。次に例を示します。

$ cc -o prog main.c -ldl
$ prog
dlopen: ld.so.1: prog: fatal: foo.so.1: open failed: No such ¥
file or directory

dlopen(3X) によって追加されたオブジェクトに、他のオブジェクトに依存する関係がある場合、その依存関係もプロセスのアドレススペースに配置されます。このプロセスは、指定されたオブジェクトの依存関係がすべて読み込まれるまで継続されます。この依存関係のツリーをグループと呼びます。

dlopen(3X) によって指定されたオブジェクト、または依存関係がすでにプロセスイメージの一部である場合は、そのオブジェクトはこれ以上処理されません。しかし、この場合でも有効なハンドルは、アプリケーションに戻されます。このメカニズムにより、同じオブジェクトが複数回対応付けされることを防ぐことができます。また、このメカニズムを使用すると、アプリケーションは専用のハンドルを入手できます。たとえば、前述した main.c の例には、次のような dlopen() 呼び出しが組み込まれている場合、

if ((handle = dlopen((const char *)0, RTLD_LAZY)) == NULL) {

dlopen(3X) から戻されたハンドルは、アプリケーションそのものの中、プロセスの初期設定の一部として読み込まれた依存関係の中、または RTLD_GLOBAL フラグが指定された dlopen(3X) を使用してプロセスのアドレススペースに追加されたオブジェクトの中のシンボルを配置できます。

再配置処理

「再配置処理」で説明したように、オブジェクトの配置および対応付け後、実行時リンカーは、各オブジェクトを処理し、必要な再配置を実行する必要があります。dlopen(3X) を使用してプロセスのアドレススペースに配置されたオブジェクトは、同じ方法で再配置する必要もあります。

単純なアプリケーションの場合には、このプロセスはまったく関係ないこともありますが、多くのオブジェクトを含む多数の dlopen(3X) 呼び出しと、おそらく共通の依存関係も伴う複雑なアプリケーションを所有するユーザーにとって、このことは非常に重要です。

再配置は、実行された時間によって分類されます。実行時リンカーのデフォルトの動作では、初期設定時にデータ参照の再配置がすべて処理され、通常レイジー結合と呼ばれるプロセスの実行時に関数参照がすべて処理されます。

この同じメカニズムは、モードが RTLD_LAZY として定義されているときに、dlopen(3X) を使用して追加されたオブジェクトに適用されます。 この代わりとしては、オブジェクトが追加されたときに、オブジェクトの再配置すべてをすぐに実行する必要があります。これは、モード RTLD_NOW を使用することによって、 または、リンカーの -z now オプションを使用して作成されたときに、オブジェクト内のこの必要条件を記録することによって実現されます。この再配置の必要条件は、オープン状態のオブジェクトの依存関係に伝達されます。

また、再配置は、非シンボリックおよびシンボリックにも分類できます。このセクションの後半では、シンボル再配置がいつ発生するかに関係なく、この再配置に関連した問題について、シンボル検索の詳細に焦点をあてて説明します。

シンボル検索

dlopen(3X) によって取得したオブジェクトが大域シンボルを参照する場合は、実行時リンカーは、プロセスを作成したオブジェクトのプールからこのシンボルを配置する必要があります。 dlopen(3X) によって入手されたオブジェクトには、デフォルトのシンボル検索モデルが適用されます。ただし、プロセスを作成したオブジェクトの属性と結合される、dlopen(3X) のモードは、代りのシンボル検索のモデルに提供されます。

オブジェクトの 2 つの属性は、シンボル検索に影響を与えます。1 つめは、オブジェクトシンボルの検索範囲の要求で、2 つめは、プロセス内の各オブジェクトが提供するシンボルの可視性です。オブジェクトの検索範囲には次のものがあります。

ワールド

オブジェクトは、プロセス内の他の大域オブジェクト内で検索されます。

グループ

オブジェクトは、同じグループ内のオブジェクト内でのみ検索されます。dlopen(3X) を使用して入手されたオブジェクトから作成された依存関係ツリー、またはリンカーの -B group オプションを使用して構築されたオブジェクトから作成れた依存関係ツリーは、固有のグループを形成します。

オブジェクトからのシンボルの可視性には、次のものがあります。

大域

オブジェクトのシンボルは、ワールド検索範囲を持つオブジェクトから参照できます。

局所

オブジェクトのシンボルは、同じグループを構成する他のオブジェクトからのみ参照されます。

デフォルトにより、dlopen(3X) を使用して入手したオブジェクトには、ワールドシンボル検索範囲と局所シンボル可視性が割り当てられます。次の項 「デフォルトのシンボル検索モデル」 では、このデフォルトモデルを使用して、典型的なオブジェクトグループの対話について説明しています。「大域オブジェクトの定義」、「グループの分離」、「オブジェクト階層」 の項では、それぞれ、デフォルトのシンボル検索の展開に dlopen(3X) モードとファイル属性を使用する例を示しています。

デフォルトのシンボル検索モデル

dlopen(3X) によって追加された各オブジェクトでは、実行時リンカーは、最初に動的実行プログラム内でシンボルを検索し、次に、プロセスの初期設定中に提供されたそれぞれのオブジェクト内を検索します。ただし、シンボルが検出されない場合には、実行時リンカーは、dlopen(3X) によって入手されたオブジェクト内と、その依存関係内の検索を続行します。

たとえば、動的実行プログラム prog と共有オブジェクト B.so.1 を入手してみましょう。この 2 つには、それぞれ以下の単純な依存関係が付いています。

$ ldd prog
        A.so.1 =>        ./A.so.1
$ ldd B.so.1
        C.so.1 =>        ./C.so.1

prog が、dlopen(3X) を使用して共有オブジェクト B.so.1 を入手した場合、共有オブジェクト B.so.1 と C.so.1 の再配置に必要なシンボルが、最初に prog 内で検索され、次に A.so.1、次に B.so.1、最後に C.so.1 が順に検索されます。このような単純なケースでは、dlopen(3X) によって入手された共有オブジェクトは、アプリケーションの元のリンク編集の末尾に追加されたと考える方が簡単な場合があります。たとえば、上記のオブジェクトの参照を図解すると、次のようになります。

図 3-1 単一の dlopen(3X) 要求

dlopen(3X) から入手されたオブジェクトによって要求されたシンボル検索は、影付きのブロックで示しています。このシンボル検索は、動的実行プログラム prog から、最後の共有オブジェクト C.so.1 へと進みます。

このシンボル検索は、読み込まれたオブジェクトに割り当てられた属性によって確立されます。動的実行プログラムとそれと同時に読み込まれたすべての依存関係には、大域シンボル可視性が割り当てられ、新しいオブジェクトには ワールドシンボルの検索範囲が割り当てられることを思いだしてください。これによって、新しいオブジェクトは元のオブジェクト内を調べてシンボルを検索できます。また、新しいオブジェクトは、固有のグループを形成し、このグループ内では、各オブジェクトは 局所シンボル可視性を持ちます。そのため、グループ内の各オブジェクトは、他のグループ構成要素内でシンボルを検索できます。

これらの新しいオブジェクトは、アプリケーションまたはその最初のオブジェクトの依存関係によって要求される、通常のシンボル検索には影響を与えません。たとえば、上記の dlopen(3X) が実行されたあとで、A.so.1 に関数再配置が必要な場合、実行時リンカーの再配置シンボルの通常の検索は、prog と A.so.1 で実施されますが、そのあとで B.so.1 または C.so.1 は検索されません。

このシンボル検索は、読み込まれたときにオブジェクトに割り当てられた属性によって実行されます。動的実行プログラムとこれとともに読み込まれた依存関係に割り当てられた ワールドシンボルの検索範囲では、局所シンボル可視性だけを提供する新しいオブジェクト内を検索できません。

これらのシンボル検索とシンボル可視性の属性は、そのプロセスのアドレススペースへの投入とオブジェクト間の依存の関係に基づいて、オブジェクト間の関係を保持します。指定された dlopen(3X) に関連したオブジェクトを割り当てることにより、固有のグループでは、同じ dlopen(3X) と関連したオブジェクトだけが、グループ内のオブジェクトと関連する依存関係の中の検索ができます。

このオブジェクト間の関係を定義するという概念は、複数の dlopen(3X) を実行するアプリケーション内では、より明確になります。たとえば、共有オブジェクト D.so.1 に次の依存関係があるとき、

$ ldd D.so.1
        E.so.1 =>         ./E.so.1

prog アプリケーションが、共有オブジェクト B.so.1 に加えて、この共有オブジェクトにも dlopen(3X) を実行した場合は、オブジェクト間のシンボル検索の関係は、下図のように表すことができます。

図 3-2 複数の dlopen(3X) 要求

B.so.1 と D.so.1 の両方にシンボル foo の定義が組み込まれ、C.so.1 と E.so.1 にこのシンボルが必要とする再配置が組み込まれている場合、固有のグループに対するオブジェクトの関係によって、C.so.1 は B.so.1 の定義に結合され、E.so.1 は D.so.1 の定義に結合されます。このメカニズムは、dlopen(3X) への複数の呼び出しにより入手されたオブジェクトの最も直感的な結合を提供するためのものです。

オブジェクトが、前述した処理の進行の中で使用される場合、それぞれの dlopen(3X) が実施された順番は、結果として発生するシンボル結合には影響しません。ただし、複数のオブジェクトに共通の依存関係がある場合は、結果の結び付きは、dlopen(3X) 呼び出しが実行された順番による影響を受けます。

次に、同じ共通依存関係を持つ共有オブジェクト O.so.1 と P.so.1 の例を示します。

$ ldd O.so.1 
        Z.so.1 =>        ./Z.so.1
$ ldd P.so.1 
        Z.so.1 =>        ./Z.so.1

この例では、prog アプリケーションは、各共有オブジェクトに dlopen(3X) を使用しています。共有オブジェクト Z.so.1 が、O.so.1 と P.so.1 両方の共通依存関係であるため、この依存関係は 2 つの dlopen(3X) 呼び出しに関連する両方のグループに割り当てられます。

図 3-3 共通依存関係を伴う複数の dlopen(3X) 要求

この結果、O.so.1 と P.so.1 の両方がシンボルの検索に Z.so.1 を使用できます。ここで重要なのは、dlopen(3X) の順序に限っていえば、Z.so.1 も O.so.1 と P.so.1 の両方の中でシンボルを検索できることです。

そのため、O.so.1 と P.so.1 の両方に、Z.so.1 の再配置に必要なシンボル foo の定義が組み込まれている場合、実際に発生する結び付きを予期することはできません。それは、この結び付きが dlopen(3X) 呼び出しの順序の影響を受けるからです。シンボル foo の機能が、シンボルが定義されている 2 つの共有オブジェクト間で異なる場合、Z.so.1 コードを実行したすべての結果は、アプリケーションの dlopen(3X) の順序によって異なる可能性があります。

大域オブジェクトの定義

dlopen(3X) によって入手されたオブジェクトへのデフォルトの局所シンボルの可視性の割り当ては、モード引数に RTLD_GLOBAL フラグを指定することによって、大域に拡大ができます。このモードでは、dlopen(3X) によって入手されたオブジェクトは、シンボルを配置するためのワールドシンボルの検索範囲の指定された他のオブジェクトによって使用することができます。

また、RTLD_GLOBAL フラグが指定された dlopen(3X) によって入手されたオブジェクトは、dlopen(0) を使用したシンボル検索にも使用できます (「追加オブジェクトの読み込み」 参照)。

局所シンボルの可視性を持つグループの構成要素が、他の大域シンボルの可視性を必要とするグループによって参照される場合、オブジェクトの可視性は局所と大域の両方を連結したものになります。このあと大域グループの参照が削除されても、この格上げされた属性はそのまま残ります。

グループの分離

dlopen(3X) によって入手されたオブジェクトへのデフォルトのワールドシンボルの検索範囲の割り当ては、モード引数に RTLD_GROUP フラグを指定することによって、グループに縮小することができます。このモードでは、dlopen(3X) によって入手されたオブジェクトは、そのオブジェクト固有のグループ内でしかシンボルの検索ができません。

オブジェクトがリンカーの -B グループ オプションを使用して構築された場合、オブジェクトには、割り当てられたグループシンボルの検索範囲があります。

グループ検索機能を持つグループの構成要素が、ワールド検索機能を必要とする他のグループによって参照された場合、オブジェクトの検索機能はグループとワールドが結合したものになります。このあとワールドグループの参照が削除されても、この格上げされた属性はそのまま残ります。

オブジェクト階層

dlopen(3X) によって入手された最初のオブジェクトが、2 番めのオブジェクトに dlopen(3X) を使用した場合、両方のオブジェクトは 1 つのグループに割り当てられます。これにより、オブジェクトが互いにシンボルを配置し合うことを防ぐことができます。

実装の中には、最初のオブジェクトの場合、シンボルを 2 番めのオブジェクトの再配置用にエキスポートする必要がある場合もあります。この必要条件は、次の 2 つのメカニズムのいずれかによって満たすことができます。

• 最初のオブジェクトを 2 番めのオブジェクトの明示的な依存関係にする

• dlopen(3X) を使用した 2 番めのオブジェクトに RTLD_PARENT モードフラグを使用する

最初のオブジェクトを 2 番めのオブジェクトの明示的な依存関係にした場合、これは 2 番めのオブジェクトのグループにも割り当てられます。そのため、最初のオブジェクトは、2 番めのオブジェクトの再配置に必要なシンボルも提供できます。

ただし、ほとんどのオブジェクトが 2 番めのオブジェクトに dlopen(3X) を実行し、これらの最初のオブジェクトが、それぞれ 2 番めのオブジェクトの再配置を満足させる同じシンボルをエキスポートする必要がある場合、2 番めのオブジェクトには明示的な依存関係を割り当てることはできません。この場合、2 番めのオブジェクトの dlopen(3X) モードは、RTLD_PARENT フラグを使用して補強できます。このフラグによって、2 番めのオブジェクトのグループが、明示的な依存関係が伝達されたのと同じ方法で、最初のオブジェクトに伝達されます。

上記の 2 つのテクニックには、1 つ小さな相違点があります。明示的な依存関係を指定する場合、その依存関係そのものは、2 番めのオブジェクトの dlopen(3X) 依存関係ツリーの一部になるため、dlopen(3X) を使用したシンボル検索が可能になります。RTLD_PARENT を使用して 2 番めのオブジェクトを入手する場合、最初のオブジェクトは、dlopen(3X) を使用したシンボルの検索に使用できるようにはなりません。

dlopen(3X) によって 2 番めのオブジェクトが、大域シンボル可視性が指定された最初のオブジェクトから入手された場合、RTLD_PARENT モードは冗長で他に影響を与えることはありません。このような状態は、dlopen(3X) がアプリケーションから呼び出されたとき、またはアプリケーションの中の依存関係の 1 つから呼び出されたときに多く発生します。

新しいシンボルの入手

プロセスは、dlsym(3X) を使用して特定のシンボルのアドレスを入手できます。この関数は、ハンドルとシンボルをとり、呼び出し元にそのシンボルのアドレスを戻します。ハンドルは、次の方法で、シンボルの検索を指示します。

• 指定されたオブジェクトの dlopen(3X) から戻されたハンドルを使用すると、オブジェクトの依存関係ツリーからシンボルを入手できる

• 値が 0 のファイルの dlopen(3X) から戻されたハンドルを使用すると、動的実行プログラム、任意の初期設定の依存関係、または RTLD_GLOBAL モードのdlopen(3X) によって入手されたオブジェクトから、シンボルを入手できる

• 特別なハンドル RTLD_DEFAULT を使用すると、動的実行プログラム、任意の初期設定の依存関係、または呼び出し元と同じグループに属する dlopen(3X) によって入手されたオブジェクトから、シンボルを入手できる (「機能のテスト」を参照)

• 特別なハンドル RTLD_NEXT を使用すると、関連するオブジェクトのネクストからシンボルを入手できる (「割り込みの使用」を参照)

最初の例は、おそらく最も一般的なものです。ここでは、アプリケーションは、追加オブジェクトをそのアドレススペースに追加し、さらに dlsym(3X) を使用して関数またはデータシンボルを配置します。次に、アプリケーションは、これらのシンボルを使用して、新しいオブジェクト内で提供されるサービスを呼び出します。たとえば、次のコードが組み込まれた main.c ファイルを取り上げてみましょう。

#include    <stdio.h>
#include    <dlfcn.h>
 
main()
{
    void *  handle;
    int *   dptr, (* fptr)();
 
    if ((handle = dlopen("foo.so.1", RTLD_LAZY)) == NULL) {
            (void) printf("dlopen: %s¥n", dlerror());
            exit (1);
    }
 
    if (((fptr = (int (*)())dlsym(handle, "foo")) == NULL) ||
        ((dptr = (int *)dlsym(handle, "bar")) == NULL)) {
            (void) printf("dlsym: %s¥n", dlerror());
            exit (1);
    }
 
    return ((*fptr)(*dptr));
}

ここで、シンボル foo と bar は、ファイル foo.so.1 内で検索された後で、このファイルに関連した依存関係が検索されます。次に、関数 foo は、単一の引数 bar によって return() ステートメントの一部として呼び出されます。

アプリケーション prog が、上記のファイル main.c を使用して構築された場合は、その最初の依存関係は次のものになります。

$ ldd prog
        libdl.so.1 =>    /usr/lib/libdl.so.1
        libc.so.1 =>     /usr/lib/libc.so.1

dlopen(3X) 内に指定されたファイル名に値 0 がある場合、シンボル foo と bar は、prog 、次に /usr/lib/libdl.so.1 、最後に /usr/lib/libc.so.1 の順番で検索されます。

ハンドルがシンボル検索を開始するルートを指示している場合は、この検索メカニズムは、「シンボルの検索」で説明したものと同じモデルに従います。

要求されたシンボルが配置されていない場合は、dlsym(3X) は、NULL 値を戻します。この場合、dlerror(3X) を使用すると、失敗の真の理由を示すことができます。次に例を示します。

$ prog
dlsym: ld.so.1: main: fatal: bar: can't find symbol

ここでは、アプリケーション prog は、シンボル bar を配置できませんでした。

機能のテスト

特別なハンドル RTLD_DEFAULT を使用すると、アプリケーションは他のシンボルの存在をテストできます。シンボル検索は、呼び出しオブジェクトを再配置する場合に使用されるものと同じモデルに従います (「再配置処理」を参照)。たとえば、アプリケーション prog に次のようなコードフラグメントが組み込まれている場合、

if ((fptr = (int (*)())dlsym(RTLD_DEFAULT, "foo")) != NULL)
        (*fptr)();

foo は、prog、/usr/lib/libdl.so.1、次に /usr/lib/libc.so.1 の順番で検索されます。このコードフラグメントが、図 3-2 の例で示すようにファイル B.so.1 に組み込まれていた場合、foo の検索は B.so.1 と C.so.1 でも継続して行われます。

このメカニズムによって、「ウィークシンボル」で説明した定義されていないウィークリファレンスの代わりに使用できる、パワフルで柔軟性のある代替機能が提供されます。

割り込みの使用

特別なハンドル RTLD_NEXT を使用すると、アプリケーションは、シンボルの範囲内で次のシンボルを配置できます。たとえば、アプリケーション prog に次のようなコードフラグメントが組み込まれている場合、

if ((fptr = (int (*)())dlsym(RTLD_NEXT, "foo")) == NULL) {
        (void) printf("dlsym: %s¥n", dlerror());
        exit (1);
}
 
return ((*fptr)());

foo は、prog に関連した共有オブジェクト内で、この場合は /usr/lib/libdl.so.1 の次に /usr/lib/libc.so.1が検索されます。このコードフラグメントが、図 3-2 の例で示すように、ファイル B.so.1 に組み込まれている場合は、foo は関連する共有オブジェクト C.so.1 の中だけで検索されます。

RTLD_NEXT を使用することによって、シンボル割り込みを活用できます。たとえば、オブジェクト関数は、オブジェクトの前に付けて割り込みでき、これにより、元の関数の処理を補強できます。次のコードフラグメントが共有オブジェクト malloc.so.1 内にある場合、以下のようになります。

#include    <sys/types.h>
#include    <dlfcn.h>
#include    <stdio.h>
 
void *
malloc(size_t size)
{
    static void * (* fptr)() = 0;
    char             buffer[50];
 
    if (fptr == 0) {
        fptr = (void * (*)())dlsym(RTLD_NEXT, "malloc");
        if (fptr == NULL) {
                (void) printf("dlopen: %s¥n", dlerror());
                return (0);
        }
    }
 
    (void) sprintf(buffer, "malloc: %#x bytes¥n", size);
    (void) write(1, buffer, strlen(buffer));
    return ((*fptr)(size));
}

この共有オブジェクトを、malloc(3C) が常駐するシステムライブラリ /usr/lib/libc.so.1 の間に割り込むことにより、元の関数呼び出されて配置が完了する前に、この関数への呼び出しが次のように割り込まれます。

$ cc -o malloc.so.1 -G -K pic malloc.c
$ cc -o prog file1.o file2.o ..... -R. malloc.so.1
$ prog
malloc: 0x32 bytes
malloc: 0x14 bytes
..........

あるいは、次のように入力しても、上記のものと同じ割り込みを実行できます。

$ cc -o malloc.so.1 -G -K pic malloc.c
$ cc -o prog main.c
$ LD_PRELOAD=./malloc.so.1 prog
malloc: 0x32 bytes
malloc: 0x14 bytes
..........

割り込みテクニックを使用する場合、反復する可能性がある処理には注意が必要です。printf(3S) を直接使用する代わりに、sprintf(3S) を使用して診断メッセージを形式し、malloc(3C) が printf(3S) を使用することによって発生する反復を防いでいます。

動的実行プログラムまたはあらかじめ読み込まれたオブジェクト内で RTLD_NEXT を使用することにより、予測可能で有用な割り込みテクニックが使用できます。ただし、このテクニックを汎用オブジェクトの依存関係内で使用する場合には、実際に読み込まれる順番が必ず予測できるとは限らないため、注意が必要です (「依存関係の並べ変え」を参照)。

機能チェッカー

リンカーによって構築された実行プログラムファイルまたは共有オブジェクトファイルは、新しい実行時リンカー機能を要求できます。実行時リンカーが実行に必要な実行時機能をサポートしているかどうかを検査するために、アプリケーション .init セクションによって関数 check_rtld_feature() が呼び出されます。現在検査された機能については、「依存関係の並べ変え」を参照してください。