test

リンカーとライブラリ

第 6 章 サポートインタフェース

概要

リンカーには、リンカーおよび実行時リンカーの処理を監視し、場合によって変更するための多数のサポートインタフェースがあります。これらのインタフェースでは、通常、前の章で説明したよりもさらに詳しくリンク編集の概念を理解する必要があります。この章では、次のインタフェースについて説明します。

リンカーのサポートインタフェース

第 2 章「リンカー」で説明したように、リンカーは、ファイルのオープンやこれらのファイルからのセクションの連結を含む多数の操作を実行します。これらの操作の監視、および場合によっては変更は、コンパイルシステムのコンポーネントにとって有益なことがよくあります。

このセクションでは、入力ファイル検査、および場合によってはリンク編集を構成するファイルの入力ファイルデータ変更用にサポートされているインタフェースついて説明します。このインタフェースは、ld-サポートインタフェースと呼ばれます。このインタフェースを使用する 2 つのアプリケーションは、このインタフェースを使用して再配置可能オブジェクト内の情報デバッグを処理するリンカーそのものと、このインタフェースを使用して状態情報を保存する make(1S) ユーティリティです。

ld-サポートインタフェースは、1 つまたは複数のサポートインタフェースルーチンを提供するサポートライブラリから構成されています。このライブラリはリンク編集プロセスの一部として読み込まれ、検出されたサポートルーチンはすべてリンク編集の各段階で呼び出されます。

このインタフェースを使用する場合は、elf(3ELF) 構造とファイル形式に詳しくなければなりません。

サポートインタフェースの呼び出し

リンカーは、SGS_SUPPORT 環境変数またはリンカーの -S オプションのどちらかによって提供される 1 つまたは複数のサポートライブラリを受け入れます。環境変数は、コロンで区切られたサポートライブラリのリストから構成されています。 


$ SGS_SUPPORT=./support.so.1:libldstab.so.1 cc ...

-S オプションは、単一のサポートライブラリを指定します。次のように複数の -S オプションを指定できます。


$ LD_OPTIONS="-S./support.so.1 -Slibldstab.so.1" cc ...

サポートライブラリは、共有オブジェクトの 1 つです。リンカーは、各サポートライブラリに対してライブラリが指定された順序で、dlopen(3DL) を実行します。環境変数と -S オプションの両方がある場合は、環境変数によって指定されたサポートライブラリが最初に処理されます。各サポートライブラリは、dlsym(3DL) によって、サポートインタフェースルーチンがないかどうかをさらに検索されます。これらのサポートルーチンは、リンク編集の各段階で呼び出されます。

注 -

デフォルトごとに、Solaris サポートライブラリ libldstab.so.1 は、リンカーを使用して、入力再配置可能オブジェクト内に提供されるコンパイラ生成デバッグ情報を処理、圧縮します。このデフォルト処理は、 -S オプションを使用して指定されたサポートライブラリでリンカーを呼び出すと抑止されます。各サポートライブラリサービスだけでなく libldstab.so.1 のデフォルト処理も必要な場合は、リンカーに提供されたサポートライブラリのリストに libldstab.so.1 を明示的に追加する必要があります。

32 ビットおよび 64 ビット環境

「新しい機能」で説明しているように、64 ビットリンカー (ld(1)) は 32 ビットのオブジェクトを生成でき、32 ビットリンカーは 64 ビットのオブジェクトを生成できます。これらのオブジェクトはそれぞれ、定義されているサポートインタフェースに関連付けられています。

64 ビットオブジェクトのサポートインタフェースは 32 ビットオブジェクトのサポートインタフェースと似ていますが、末尾に「64」という接尾辞が付きます。たとえば、ld_start() および ld_start64() のようになります。この規則により、サポートインタフェースの両方の実装状態を、libldstab.so.1 という単一の共有オブジェクトの 32 ビットと 64 ビットの各クラスに常駐させることができます。

サポートインタフェース関数

ld-サポートインタフェースはすべて、ヘッダファイル link.h に定義されています。インタフェース引数はすべて、基本的な C タイプまたは ELF タイプです。ELF データタイプは、ELF アクセスライブラリ libelf によって調べることができます (libelf の内容については、elf(3ELF) を参照)。次のインタフェース関数は、ld-サポートインタフェースによって提供されており、予定の使用順序に従って記述されています。

ld_start() 

void ld_start(const char * name, const Elf32_Half type,
    const char * caller);

void ld_start64(const char * name, const Elf64_Half type,
    const char * caller);

この関数は、リンカーコマンド行の初期妥当性検査の後に呼び出されて、入力ファイル処理の開始を示します。

name は、作成される出力ファイル名を示します。type は出力ファイルタイプであり、ET_DYN、ET_REL、ET_EXEC のどれかです (sys/elf.h に定義)。caller は、インタフェースを呼び出すアプリケーションを示します。これは通常、/usr/ccs/bin/ld です。

ld_file() 

void ld_file(const char * name, const Elf_Kind kind, int flags,
    Elf * elf);

void ld_file64(const char * name, const Elf_Kind kind, int flags,
    Elf * elf);

この関数は、ファイルデータの処理が実行される前に、各入力ファイルに対して呼び出されます。

name は処理される入力ファイルを示します。kind は入力ファイルのタイプを示し、 ELF_K_AR または ELF_K_ELF のどちらかになります (libelf.h に定義)。flags は、リンカーによるファイルの取得方法を示し、次の 1 つまたは複数の定義にすることができます。

  • LD_SUP_DERIVED - ファイル名はコマンド行に明示的に指定されていない。 -l の拡張から派生するか、または抽出されたアーカイブ構成要素を示す

  • LD_SUP_INHERITED - ファイルは、コマンド行共有オブジェクトの依存関係として取得される

  • LD_SUP_EXTRACTED - ファイルは、アーカイブから抽出される

flags 値が指定されていない場合、入力ファイルはコマンド行に明示的に指定されています。elf は、ファイル ELF 記述子へのポインタです。

ld_section() 

void ld_section(const char * name, Elf32_Shdr * shdr,
        Elf32_Word sndx, Elf_Data * data, Elf * elf);
void ld_section64(const char * name, Elf64_Shdr * shdr,
        Elf64_Word sndx, Elf_Data * data, Elf * elf);

この関数は、セクションデータの処理が実行される前に、入力ファイルの各セクションに対して呼び出されます。

name は、入力セクション名を示します。shdr は、関連のセクションヘッダへのポインタを示します。sndx は、入力ファイル内のセクションインデックスです。data は、関連データバッファへのポインタを示します。elf は、ファイル ELF 記述子へのポインタです。

データの変更は、データ自体を再割り当てして、Elf_Data バッファに d_buf ポインタを再割り当てすることによって可能になります。データへの変更はすべて、Elf_Data バッファの d_size 要素を保証しなければなりません。出力イメージの一部になる入力セクションでは、d_size 要素をゼロに設定すると、出力イメージからデータが効率的に削除されます。

注 -

リンカーの -s オプションによって取り除かれるセクションは、ld_section() に報告されません。

ld_atexit() 

void ld_atexit(int status);

void ld_atexit64(int status);

この関数は、リンク編集の終了時に呼び出されます。

status は、リンカーによって返される exit(2) コードであり、EXIT_FAILURE または EXIT_SUCCESS のどちらかです (stdlib.h に定義)。

サポートインタフェースの例

次の例では、32 ビットリンク編集の一部として処理される再配置可能オブジェクトファイルのセクション名 (表 7-16 を参照) を出力するサポートライブラリを作成しています。


$ cat support.c
#include        <link.h>
 
static int      indent = 0;
 
void
ld_start(const char * name, const Elf32_Half type,
    const char * caller)
{
        (void) printf("output image: %s¥n", name);
}
 
void
ld_file(const char * name, const Elf_Kind kind, int flags,
    Elf * elf)
{
        if (flags & LD_SUP_EXTRACTED)
                indent = 4;
        else
                indent = 2;
 
        (void) printf("%*sfile: %s¥n", indent, "", name);
}
 
void
ld_section(const char * name, Elf32_Shdr * shdr, Elf32_Word sndx,
    Elf_Data * data, Elf * elf)
{
        Elf32_Ehdr *    ehdr = elf32_getehdr(elf);
 
        if (ehdr->e_type == ET_REL)
                (void) printf("%*s   section [%ld]: %s¥n", indent,
                    "", sndx, name);
}

このサポートライブラリは、libelf に依存して、入力ファイルタイプを判定するために使用される ELF アクセス関数 elf32_getehdr(3ELF) を提供します。サポートライブラリは、次の行によって構築されます。


$ cc -o support.so.1 -G -K pic support.c -lelf -lc

次の例は、再配置可能オブジェクトおよび局所範囲アーカイブライブラリによる簡易アプリケーションの構築の結果生じたセクション診断を示しています。 -S オプションを使用すると、デフォルトデバッグ情報処理だけでなく、サポートライブラリの呼び出しも行われます。


$ LD_OPTIONS="-S./support.so.1 -Slibldstab.so.1" ¥ 
cc -o prog main.c -L. -lfoo

output image: prog
  file: /opt/COMPILER/crti.o
     section [1]: .shstrtab
     section [2]: .text
     .......
  file: /opt/COMPILER/crt1.o
     section [1]: .shstrtab
     section [2]: .text
     .......
  file: /opt/COMPILER/values-xt.o
     section [1]: .shstrtab
     section [2]: .text
     .......
  file: main.o
     section [1]: .shstrtab
     section [2]: .text
     .......
  file: ./libfoo.a
    file: ./libfoo.a(foo.o)
       section [1]: .shstrtab
       section [2]: .text
       .......
  file: /usr/lib/libc.so
  file: /opt/COMPILER/crtn.o
     section [1]: .shstrtab
     section [2]: .text
     .......
  file: /usr/lib/libdl.so.1
注 -

この例で表示されるセクションの数は、出力を簡素化するために減らされています。また、コンパイラドライバによって取り込まれるファイルも異なる場合があります。

実行時リンカーの監査インタフェース

第 3 章「実行時リンカー」で説明したように、実行時リンカーは、メモリーへのオブジェクトの割り当てや記号の結合を含む多数の操作を実行します。これらの操作を同じプロセス内から監視、および場合によっては変更すると強力なプロセス監視ツールになります。

このセクションでは、プロセスに関する実行時リンク情報にアクセスするために、そのプロセスにサポートされているインタフェースについて説明します。このインタフェースは rtld-監査インタフェースと呼ばれます。この機構の使用例としては、「共有オブジェクトのプロファイリング」で説明している共有オブジェクトの実行時プロファイルがあります。

rtld-監査インタフェースは、1 つまたは複数の監査インタフェースルーチンを提供する監査ライブラリとして実装されます。このライブラリがプロセスの一部として読み込まれている場合は、プロセス実行の各段階で、実行時リンカーによって監査ルーチンが呼び出されます。これらのインタフェースを使用すると、監査ライブラリは次のものにアクセスできます。

これらの機能のいくつかは、特殊な共有オブジェクトを事前に読み込むことによって実現できます (「追加オブジェクトの読み込み」を参照)。ただし、事前に読み込まれたオブジェクトは、プロセスのオブジェクトと同じ名前空間内にあります。このことは、通常、事前に読み込まれた共有オブジェクトの実装を制限したり、複雑化したりします。rtld-監査インタフェースは、ユーザーに対して、監査ライブラリを実行するための固有の名前空間を提供します。 これにより、監査ライブラリがプロセス内で発生する通常の結合を妨害することはなくなります。

名前空間の確立

実行時リンカーは、動的実行可能なプログラムをその依存関係と結合すると、リンクマップのリンクリストを構築して、プロセスを記述します。リンクマップ構造は、プロセス内の各オブジェクトを記述し、/usr/include/sys/link.h に定義されます。アプリケーションのオブジェクトを結合するために必要な記号検索機構は、このリンクマップリストを検索します。このリンクマップリストは、プロセス記号解決用の名前空間を提供します。

実行時リンカー自体もリンクマップによって記述されると、このリンクマップは、アプリケーションオブジェクトのリストとは異なるリストに維持されます。この結果、実行時リンカーは各自の固有名前空間に常駐することなるため、実行時リンカー内のサービスにアプリケーションが直接結合されることはなくなります (アプリケーションは、フィルタ libdl.so.1 を介してのみ、実行時リンカーの公共サービスを要求できます)。

rtld-監査インタフェースは、すべての監査ライブラリを保持するための各自のリンクマップリストを使用します。この結果、監査ライブラリは、アプリケーションの記号結合条件から分離されます。アプリケーションリンクマップリストの検査は、dlmopen(3DL) によって実行できます。これは、RTLD_NOLOAD フラグとともに使用すると、監査ライブラリで、オブジェクトを読み込むことなくその存在を照会することができます。

アプリケーションと実行時リンカーのリンクマップリストを定義するために、2 つの識別子が /usr/include/link.h に定義されています。


#define LM_ID_BASE      0     /* application link-map list */
#define LM_ID_LDSO      1     /* runtime linker link-map list */

各 rtld-監査サポートライブラリには、固有の空きリンクマップ識別子が割り当てられています。

監査ライブラリの構築

監査ライブラリは他の共有オブジェクトと同様に構築されますが、プロセス内の固有名前空間には、いくつかの注意が必要です。

監査ライブラリが printf(3C) を呼び出す場合、その監査ライブラリは、libc への依存関係を定義しなければなりません (「共有オブジェクトの生成」を参照)。監査ライブラリには、固有の名前空間があるため、監査中のアプリケーションに存在する libc によって記号参照を満たすことはできません。監査ライブラリに libc への依存関係がある場合は、2 つのバージョンの libc.so.1 がプロセスに読み込まれます。1 つはアプリケーションのリンクマップリストの結合条件を満たし、もう 1 つは監査リンクマップリストの結合条件を満たします。

すべての依存関係が記録された状態で監査ライブラリが構築されるようにするには、リンカーの -z defs オプションを使用します (「共有オブジェクトの生成」を参照)。

システムインタフェースには、プロセスにおける実装状態の唯一のインスタンスであると想定して存在するものもあります。たとえば、スレッド、シグナル、および malloc(3C) などです。このようなインタフェースを使用すると、アプリケーションの動作が不正に変更されるおそれがあるため、監査ライブラリでは、このようなインタフェースの使用を避ける必要があります。

注 -

mapmalloc(3MALLOC) を使用した監査ライブラリによるメモリー割り当ては受け入れられます。これは、アプリケーションによって通常使用される割り当てスキーマとこの割り当てが共存可能なためです。

監査インタフェースの呼び出し

rtld_audit インタフェースは、次のいずれかの方法によって有効になります。それぞれの方法は、監視対象のオブジェクトの範囲を意味します。

それぞれの呼び出し方法は、dlmopen(3DL) によって読み込まれる共有オブジェクトをコロンで区切ったリストを含む文字列で構成されています。各オブジェクトは、各自の監査リンクマップリストに読み込まれます。また、各オブジェクトは、dlsym(3DL) によって、監査ルーチンがないか検索されます。検出された監査ルーチンは、アプリケーション実行中に各段階で呼び出されます。

rtld_audit インタフェースを使用すると、複数の監査ライブラリを与えることができます。この方法で使用される監査ライブラリは、通常実行時リンカーによって返される結合を変更することはできません。もし変更すると、後に続く監査ライブラリで予期しない結果が生じます。

安全なアプリケーション (「動的依存関係のレイジーローディング」を参照) は、トラステッドディレクトリから監査ライブラリだけを取得できます。現在監査ライブラリに使用できるトラステッドディレクトリは、32 ビットオブジェクトの場合は /usr/lib/secure と 、64 ビットオブジェクトの場合は /usr/lib/secure/sparcv9 だけです。

ローカル監査の記録

ローカル監査要求は、オブジェクトがリンカーオプション -p あるいは -P を使用して作成された場合に確立できます。開発者が、共有オブジェクト libfoo.so.1 の使用状況を、監査ライブラリ audit.so.1 を使用して監査したい場合は、リンク編集時に -p オプションを使用してこの要求を記録すれば、その監査を行うことができます。 


$ cc -G -o libfoo.so.1 -Wl,-paudit.so.1 -Kpic foo.c
$ dump -Lv libfoo.so.1 | fgrep AUDIT
[3]    AUDIT      audit.so.1

実行時には、この監査識別子があることにより監査ライブラリが読み込まれ、識別するオブジェクトに関する情報がその監査ライブラリに渡されます。

ただし、この仕組みだけでは、識別するオブジェクトの検索などの情報は監査ライブラリが読み込まれる前に発生してしまいます。できるだけ多くの監査情報を提供するため、ローカル監査を要求するオブジェクトの存在は、そのオブジェクトのユーザーに広く知らされます。たとえば、libfoo.so.1 に依存するアプリケーションを作成すると、そのアプリケーションは、その依存関係の監査が必要であることを示すよう認識されます。


$ cc -o main main.c libfoo.so.1
$ dump -Lv main | fgrep AUDIT
[5]    DEPAUDIT   audit.so.1

この仕組みによって使用できる監査の結果、監査ライブラリが読み込まれ、アプリケーションの明白な依存関係すべてに関する情報が渡されます。この依存関係の監査は、リンカーの -P オプションを使用することにより、オブジェクトの作成時に直接記録することもできます。


$ cc -o main main.c -Wl,-Paudit.so.1
$ dump -Lv main | fgrep AUDIT
[5]    DEPAUDIT   audit.so.1

監査インタフェースの関数

次の関数が rtld-監査インタフェースによって提供されており、予定の使用順序で記述されます。

注 -

アーキテクチャあるいはオブジェクトクラス固有のインタフェースの参照は、説明を簡潔にするために、通常は総称に省略します。たとえば、la_symbind32() および la_symbind64() は la_symbind() で表します。

la_version() 

uint_t la_version(uint_t version);

この関数は、実行時リンカーと監査ライブラリの間に初期接続を提供します。このインタフェースを読み込むには、監査ライブラリによってこれを提供する必要があります。

実行時リンカーは、サポート可能な最上位バージョンの rtld-監査によって、このインタフェースを呼び出します。監査ライブラリは、このバージョンが十分に使用できるかどうかを確認して、使用する予定のバージョンを返すことができます。このバージョンは、通常、/usr/include/link.h に定義されている LAV_CURRENT です。

監査ライブラリがゼロのバージョン、または実行時リンカーがサポートする rtld-監査インタフェースよりも大きい値を返す場合は、監査ライブラリは使用されません。

la_activity() 

void la_activity(uintptr_t * cookie, uint_t flag);

この関数は、リンク対応付けアクティビティが行われていることを監査プログラムに知らせます。

cookie は、リンク対応付けの先頭のオブジェクトを指します。flags は、/usr/include/link.h に定義されているものと同じタイプのアクティビティを指します。

  • LA_ACT_ADD ― リンク対応付けリストにオブジェクトが追加される

  • LA_ACT_DELETE ― リンク対応付けリストからオブジェクトが削除される

  • LA_ACT_CONSISTENT ― オブジェクトのアクティビティが完了した

la_objsearch() 

char * la_objsearch(const char * name, uintptr_t * cookie, uint_t flag);

この関数は、オブジェクトの検索が行われていることを監査プログラムに知らせます。

name は、検索しているファイルあるいはパス名を指します。cookie は、検索を開始しているオブジェクトを指します。flags は、/usr/include/link.h に定義されているものと同じ name の起因を指します。

  • LA_SER_ORIG ― 最初の検索名。通常、DT_NEEDED エントリとして記録されたファイル名あるいは dlmopen(3DL) に与えられた引数を指す

  • LA_SER_LIBPATH ― 名前が LD_LIBRARY_PATH エントリから作成されている

  • LA_SER_RUNPATH ― 名前が「実行パス」エントリから作成されている

  • LA_SER_CONFIG ― 名前が、構成ファイルで指定されたデフォルトの検索パスエントリから作成されている (crle(1) のマニュアルページを参照)

  • LA_SER_DEFAULT ― 名前がデフォルトの検索パスエントリから作成されている

  • LA_SER_SECURE - LA_SER_CONFIG および LA_SER_DEFAULT に追加され、デフォルトのパスエントリがセキュアオブジェクトに適用されることを示す

戻り値は、実行時リンカーが処理を継続する必要がある検索パス名を示し、値 0 は、このパスが無視されることを示します。検索パスを監視する監査ライブラリは、name を返します。

la_objopen() 

uint_t la_objopen(Link_map * lmp, Lmid_t lmid, uintptr_t * cookie);

この関数は、新しいオブジェクトが実行時リンカーによって読み込まれるたびに呼び出されます。

lmp は、新しいオブジェクトを記述するリンクマップ構造を提供します。lmid は、オブジェクトが追加されているリンクマップリストを特定します (「名前空間の確立」を参照)。cookie は、識別子へのポインタを提供します。この識別子は、オブジェクト lmp に初期設定されますが、監査ライブラリによって、オブジェクトを他の rtld-監査インタフェースルーチンに対して特定するように変更できます。

この関数は、このオブジェクトで問題になるシンボル結合を示す値を返し、後に la_symbind() を呼び出します。この結果の値は、/usr/include/link.h に定義された次の値のマスクです。

  • LA_FLG_BINDTO - このオブジェクトに対する監査シンボル結合

  • LA_FLG_BINDFROM - このオブジェクトからの監査シンボル結合

これらの 2 つのフラグ使用法については、la_symbind() を参照してください。

ゼロの戻り値は、結合情報がこのオブジェクトで問題にならないことを示します。

la_preinit() 

void la_preinit(uintptr_t * cookie);

この関数は、すべてのオブジェクトがアプリケーションに読み込まれた後で、アプリケーションへの制御の譲渡が発生する前に一度呼び出されます。

cookie は、プロセスを開始したプライマリオブジェクト、通常は動的実行可能プログラムを表します。

la_symbind() 

uintptr_t la_symbind32(Elf32_Sym * sym, uint_t ndx,
       uintptr_t * refcook, uintptr_t * defcook, uint_t * flags);
 
uintptr_t la_symbind64(Elf64_Sym * sym, uint_t ndx,
       uintptr_t * refcook, uintptr_t * defcook, uint_t * flags,
	      const char * sym_name);

この関数は、結合通知のタグが付けられた 2 つのオブジェクト間で結合が発生すると呼び出されます (la_objopen()を参照)。

sym は、構築された記号構造 (/usr/include/sys/elf.h を参照) であり、sym->st_value は結合中の記号定義のアドレスを示します。la_symbind32() は、sym->st_name を調整して実際の記号名を指していますが、la_symbind64() は sym->st_name を結合オブジェクトの文字列テーブルのインデックスのままにしています。

ndx は、結合オブジェクト動的記号テーブル内の記号インデックスを示します。refcook は、この記号への参照を行うオブジェクトを記述します。この識別子は、LA_FLG_BINDFROM を返した la_objopen() に渡されたものと同じです。defcook は、この記号を定義するオブジェクトを記述します。この識別子は、LA_FLG_BINDTO を返した la_objopen() に渡されるものと同じです。

flags は、手続きリンクテーブル記号エントリの連続監査を変更するために使用できるデータ項目を指します。この値は、/usr/include/link.h に定義された次のフラグのマスクです。

  • LA_SYMB_NOPLTENTER - la_pltenter() 関数は、この記号に対しては呼び出されない

  • LA_SYMB_NOPLTEXIT - la_pltexit() 関数は、この記号に対しては呼び出されない

  • LA_SYMB_DLSYM - dlsym(3DL) を呼び出した結果発生したシンボル結合

  • LA_SYMB_ALTVALUE (LAV_VERSION2) -la_symbind() への以前の呼び出しによって、記号値に対して代替値が返される

デフォルトにより、la_pltenter() または la_pltexit() 関数が監査ライブラリ内に存在する場合、シンボルが参照されるたびに、これらは手続きリンクテーブル記号に対して、la_symbind() の後で呼び出されます (「監査インタフェースの制限」も参照)。

戻り値は、この呼び出しに続いて制御を渡す必要があるアドレスを示します。シンボル結合を監視するだけの監査ライブラリは、sym->st_value の値を返すため、制御は結合記号定義に渡されます。監査ライブラリは、異なる値を返すことによって、シンボル結合を意図的にリダイレクトできます。

sym_name は、la_symbind64() のみに適用されますが、処理されるシンボルの名前を含みます。これは、32 ビットインタフェースから sym->st_name フィールドで使用できます。

la_pltenter() 

uint_t la_sparcv8_pltenter(Elf32_Sym * sym, uint_t ndx,
        uintptr_t * refcook, uintptr_t * defcook,
        La_sparcv8_regs * regs, uint_t * flags);
 
uint_t la_sparcv9_pltenter(Elf64_Sym * sym, uint_t ndx,
        uintptr_t * refcook, uintptr_t * defcook,
        La_sparcv9_regs * regs, uint_t * flags,
        const char * sym_name);
 
uint_t la_i86_pltenter(Elf32_Sym * sym, uint_t ndx,
        uintptr_t * refcook, uintptr_t * defcook,
        La_i86_regs * regs, uint_t * flags);

これらの関数は、結合通知のタグが付けられた 2 つのオブジェクト間の手続きリンクシンボルエントリが呼び出されると、SPARC および IA システムでそれぞれ呼び出されます (la_objopen() と la_symbind() を参照)。

sym、ndx、refcook、defcook、および sym_name は、la_symbind() に渡されたものと同じ情報を提供します。

regs は、/usr/include/link.h に定義されているように、SPARC システム上のout レジスタと、IA システム上の stack および frame レジスタを指します。

flags は、手続きリンクテーブルエントリの連続監査を変更するために使用できるデータ項目を指します。このデータ項目は、la_symbind() から flags によって指されるものと同じです。この値は、/usr/include/link.h に定義された次のフラグのマスクです。

  • LA_SYMB_NOPLTENTER - la_pltenter() は、この記号では再び呼び出されない

  • LA_SYMB_NOPLTEXIT - la_pltexit() は、この記号では呼び出されない

戻り値は、この呼び出しに続いて制御を渡す必要があるアドレスを示します。シンボル結合を監視するだけの監査ライブラリは、sym->st_value の値を返すため、制御は結合記号定義に渡されます。監査ライブラリは、異なる値を返すことによって、シンボル結合を意図的にリダイレクトできます。

la_pltexit() 

uint_t la_pltexit(Elf32_Sym * sym, uint_t ndx, uintptr_t * refcook,
        uintptr_t * defcook, uintptr_t retval);

uint_t la_pltexit64(Elf64_Sym * sym, uint_t ndx, uintptr_t * refcook,
        uintptr_t * defcook, uintptr_t retval, const char * sym_name);

この関数は、結合通知のタグが付けられた 2 つのオブジェクト間の手続きリンク記号項目 (la_objopen() と la_symbind() を参照) が返されて、制御が呼び出し側に到達するまでの間に呼び出されます。

sym、ndx、refcook、 defcook、および syn_name は、la_symbind() に渡されるものと同じ情報を提供します。retval は結合関数からの戻りコードです。シンボル結合を監視する監査ライブラリは、retval を返します。監査ライブラリは意図的に異なる値を返すことができます。

注 -

このインタフェースは実験的なものです。 「監査インタフェースの制限」を参照してください。

la_objclose() 

uint_t la_objclose(uintptr_t * cookie);

この関数はオブジェクトに対する終了コードが実行されてから、オブジェクトが読み込みを解除されるまでに呼び出されます (「デバッギングエイド」を参照)。

cookie は、以前の la_objopen() から取得されていて、オブジェクトを特定します。戻り値は、ここではすべて無視されます。

監査インタフェースの例

次の単純な例では、動的実行可能プログラム date(1) によって読み込まれた各共有オブジェクトの依存関係の名前を出力する、監査ライブラリを作成しています。


$ cat audit.c
#include        <link.h>
#include        <stdio.h>
 
uint_t
la_version(uint_t version)
{
        return (LAV_CURRENT);
}
 
uint_t
la_objopen(Link_map * lmp, Lmid_t lmid, uintptr_t * cookie)
{
        if (lmid == LM_ID_BASE)
                (void) printf("file: %s loaded¥n", lmp->l_name);
        return (0);
}
$ cc -o audit.so.1 -G -K pic -z defs audit.c -lmapmalloc -lc
$ LD_AUDIT=./audit.so.1 date
file: date loaded
file: /usr/lib/libc.so.1 loaded
file: /usr/lib/libdl.so.1 loaded
file: /usr/locale/en_US/en_US.so.1 loaded
Fri Mar  8 10:03:55 PST 1997

監査インタフェースのデモンストレーション

/usr/demo/link_audit の SUNWosdem パッケージには、rtld-監査インタフェースを使用する多数のデモアプリケーションが用意されています。

sotruss

このデモアプリケーションは、指定アプリケーションの動的オブジェクト間での手続き呼び出しを追跡します。

whocalls

このデモアプリケーションは、指定アプリケーションに呼び出されるたびに、指定関数のスタックと追跡を行います。

perfcnt

このデモアプリケーションは、指定アプリケーションの各関数で費やされた時間を追跡します。

symbindrep

このデモアプリケーションは、指定アプリケーションを読み込むために実行されたすべてのシンボル結合を報告します。

sotruss(1) と whocalls(1) は、SUNWtoo パッケージにも組み込まれています。 perfcnt と symbindrep はサンプルプログラムであり、実際の環境での使用を目的としていません。

監査インタフェースの制限

la_pltexit() 系列の使用にはいくつかの制限があります。これらの制限は、呼び出し側と呼び出し先の間で余分なスタックフレームを挿入して、la_pltexit() 戻り値を獲得する方法を提供するための必要から生じたものです。la_pltenter() ルーチンだけを呼び出す場合には、妨害となるスタックを整理してから宛先関数に制御を譲渡できるため、上記は問題になりません。

これらの制限が原因で、la_pltexit() は、上記の制限を改善するために今後のリリースで変更される可能性がある、実験的インタフェースとみなされます。問題がある場合には、la_pltexit() ルーチンを避けるようにしてください。

スタックを直接検査する関数

スタックを直接検査するか、またはその状態について仮定をたてる少数の関数があります。これらの関数の例としては、setjmp(3C) ファミリ、vfork(2)、および構造へのポインタではなく構造を返す関数があります。これらの関数は、la_pltexit() をサポートするために作成される余分なスタックによって調整されます。

実行時リンカーは、このタイプの関数を検出できないため、監査ライブラリの作成元が、このようなルーチンの la_pltexit() を無効にする必要があります。

実行時リンカーのデバッガインタフェース

第 3 章「実行時リンカー」で説明したように、実行時リンカーは、メモリーへのオブジェクトの割り当てやシンボルの結合を含む多数の操作を実行します。デバッグプログラムは、通常、これらの実行時リンカーの操作をアプリケーション解析の一部として記述する情報にアクセスする必要があります。これらのデバッグプログラムは、解析対象のアプリケーションに対する独立したプロセスとして実行されます。

このセクションでは、他のプロセスから動的にリンクされたアプリケーションを監視、変更するためにサポートされているインタフェースを説明します。このインタフェースは、rtld-デバッガインタフェースと呼ばれます。このインタフェースのアーキテクチャは、libthread_db(3THR) で使用されるモデルに従っています。

rtld-デバッガインタフェースを使用する場合は、少なくとも次の 2 つのプロセスが関与します。

rtld-デバッガは、制御プロセスがデバッガであり、そのターゲットが動的実行可能なプログラムの場合に、最もよく使用されます。

rtld-デバッガインタフェースは、ターゲットプロセスに対して次のものを有効にします。

制御プロセスとターゲットプロセス間の対話

ターゲットプロセスを検査して操作できるようにするために、rtld-デバッガインタフェースは、エクスポートされたインタフェース、インポートされたインタフェース、およびエージェントを使用して、これらのインタフェース間で通信を行います。

制御プロセスは、librtld_db.so.1 によって提供される rtld-デバッガインタフェースにリンクされて、このライブラリからエクスポートされたインタフェースを要求します。このインタフェースは、/usr/include/rtld_db.h に定義されています。次に、librtld_db.so.1 は制御プロセスからインポートされたインタフェースを要求します。この対話によって、rtld-デバッガ インタフェースは、次のことを行うことができます。

インポートされたインタフェースは多数の proc_service ルーチンから構成されています (「デバッガインポートインタフェース」を参照) 。ほとんどのデバッガは、このルーチンをすでに使用してプロセスを解析しています。

rtld-デバッガインタフェースは、rtld-デバッガインタフェースの要求により解析中のプロセスが停止することを前提としています。停止しない場合は、ターゲットプロセスの実行時リンカー内にあるデータ構造が、検査時に一貫した状態にない可能性があります。

図 6-1 は、librtld_db.so.1、制御プロセス (デバッガ)、およびターゲットプロセス (動的実行可能プログラム) 間の情報の流れを示しています。

図 6-1 rtld-デバッガの情報の流れ

Graphic

注 -

rtld-デバッガインタフェースは、実験的と見なされる proc_service インタフェース (/usr/include/proc_service.h) に依存します。rtld-デバッガインタフェースは、展開時に、proc_service インタフェース内の変更を追跡しなければならないことがあります。

rtld-デバッガインタフェースを使用する制御プロセスのサンプル実装状態は、/usr/demo/librtld_db の SUNWosdem パッケージに用意されています。 このデバッガ rdb は、proc_service インポートインタフェースの使用例を提示して、すべての librtld_db.so.1 インポートインタフェースの使用例を提示して、すべての rtld-デバッガインタフェースについて説明します。さらに詳しい情報は、サンプルデバッガをテストして得ることができます。

デバッガインタフェースのエージェント

エージェントは、内部インタフェース構造を記述できる不透明なハンドルを提供して、エクスポートインタフェースとインポートインタフェースの間の通信機構となるものです。rtld-デバッガインタフェースは、いくつかのプロセスを同時に操作できるデバッガによる使用を目的としているため、これらのエージェントは、プロセスを特定するために使用されます。

struct ps_prochandle 

struct ps_prochandle;

制御プロセスによって、エクスポートインタフェースとインポートインタフェースの間で渡されるターゲットプロセスを特定するために作成される不透明な構造です。

struct rd_agent 

struct rd_agent;

rtld-デバッガインタフェースによって、エクスポートインタフェースとインポートインタフェースの間で渡されるターゲットプロセスを特定するために作成される不透明な構造です。

デバッガエクスポートインタフェース

このセクションでは、/usr/lib/librtld_db.so.1 監査ライブラリによってエクスポートされる各インタフェースについて説明します。この節は、機能グループごとに分けられています。

エージェント操作

rd_init() 

rd_err_e rd_init(int version);

この関数は、rtld-デバッガバージョン条件を確立します。現在バージョンは、RD_VERSION によって定義されます。

制御プロセスのバージョン条件が使用可能な rtld-デバッガインタフェースよりも大きい場合は、RD_NOCAPAB が返されます。

rd_new() 

rd_agent_t * rd_new(struct ps_prochandle * php);

この関数は、新しいエクスポートのインタフェースエージェントを作成します。「php」は、制御プロセスによってターゲットプロセスを特定するために作成された cookie です。この cookie は、制御プロセスによってコンテキストを維持するために提供される重要なインタフェースで使用されるものであり、rtld-デバッガインタフェースに対して不透明です。

rd_reset() 

rd_err_e rd_reset(struct rd_agent * rdap);

この関数は、rd_new() に指定された同じ ps_prochandle 構造に基づくエージェント内の情報をリセットします。この関数は、ターゲットプロセスが再スタートされると呼び出されます。

rd_delete() 

void rd_delete(struct rd_agent * rdap);

この関数は、エージェントを削除し、それに関連するすべての状態を解除します。

エラー処理

次のエラー状態は、rtld-デバッガインタフェース (rtld_db.h に定義) によって返されます。


typedef enum {
        RD_ERR,
        RD_OK,
        RD_NOCAPAB,
        RD_DBERR,
        RD_NOBASE,
        RD_NODYNAM,
        RD_NOMAPS
} rd_err_e;

次のインタフェースは、エラー情報を収集するために使用できます。

rd_errstr() 

char * rd_errstr(rd_err_e rderr);

この関数は、エラーコード「rderr」を記述する記述エラー文字列を返します。

rd_log() 

void rd_log(const int onoff);

この関数は、ログ記録をオン (1) またはオフ (0) にします。ログ記録がオンの場合、制御プロセスによって提供されるインポートインタフェース関数 ps_plog() は、さらに詳しい診断情報によって呼び出されます。

読み込み可能オブジェクトの走査

実行時リンカーのリンクマップで維持される各オブジェクト情報の取得は (「名前空間の確立」を参照)、rtld_db.h に定義された次の構造を使用して実現されます。


typedef struct rd_loadobj {
        psaddr_t        rl_nameaddr;
        unsigned        rl_flags;
        psaddr_t        rl_base;
        psaddr_t        rl_data_base;
        unsigned        rl_lmident;
        psaddr_t        rl_refnameaddr;
        psaddr_t        rl_plt_base;
        unsigned        rl_plt_size;
        psaddr_t        rl_bend;
        psaddr_t        rl_padstart;
        psaddr_t        rl_padend;
} rd_loadobj_t;

文字列ポインタを含めて、この構造で指定されるアドレスはすべてターゲットプロセス内のアドレスであり、制御プロセス自体のアドレス空間のアドレスでないことに注意してください。

rl_nameaddr

動的オブジェクトの名前を含む文字列へのポインタ

rl_flags

今後の使用のために予約

rl_base

動的オブジェクトの基本アドレス

rl_data_base

動的オブジェクトのデータセグメントの基本アドレス

rl_lmident

リンクマップ識別子 (「名前空間の確立」を参照)

rl_refnameaddr

動的オブジェクトがフィルタの場合は (「フィルタとしての共有オブジェクト」を参照)、フィルタ対象の名前を指定する

rl_plt_base, rl_plt_size

これらの要素は、下方互換性のために存在するものであり、現在は使用されていない

rl_bend

オブジェクトのエンドアドレス (text + data + bss)

rl_padstart

動的オブジェクト前のパッドの基本アドレス (「動的オブジェクトのパッド」を参照)

rl_padend

動的オブジェクト後のパッドの基本アドレス (「動的オブジェクトのパッド」を参照)

次のルーチンは、このオブジェクトデータ構造を使用して実行時リンカーリンクマップリストの情報にアクセスしています。

rd_loadobj_iter() 

typedef int rl_iter_f(const rd_loadobj_t *, void *);
 
rd_err_e rd_loadobj_iter(rd_agent_t * rap, rl_iter_f * cb,
        void * clnt_data);

この関数は、ターゲットプロセスに現在読み込まれている動的オブジェクトすべてを反復します。各反復時に、cb によって指定されたインポート関数が呼び出されます。clnt_data は、cb 呼び出しにデータを渡すために使用できます。各オブジェクトに関する情報は、スタックが割り当てられた volatile rd_loadobj_t 構造へのポインタを介して返されます。

cb ルーチンからの戻りコードは、rd_loadobj_iter() によってテストされ、次の意味を持ちます。

  • 1 - リンクマップの処理を継続

  • 0 - リンクマップの処理を停止して、制御プロセスに制御を返す

rd_loadobj_iter() は、正常だと RD_OK を返します。RD_NOMAPS が返される場合、実行時リンカーは、まだ初期リンクマップを読み込みません。

イベント通知

実行時リンカーの適用範囲内で発生し、制御プロセスが追跡できる特定のイベントがあります。これらのイベントは次のとおりです。

RD_PREINIT

実行時リンカーは、すべての動的オブジェクトを読み込んで再配置し、読み込まれた各オブジェクトの .init セクションの呼び出しを開始 (「デバッギングエイド」を参照)。

RD_POSTINIT

実行時リンカーは、すべての .init セクションの呼び出しを終了して、基本実行可能プログラムに制御を渡す。

RD_DLACTIVITY

実行時リンカーは、動的オブジェクトを読み込みまたは読み込み解除のために呼び出される (「追加オブジェクトの読み込み」を参照)。

これらのイベントは、次のインタフェース (sys/link.h と rtld_db.h に定義) を使用して監視できます。


typedef enum {
        RD_NONE = 0,
        RD_PREINIT,
        RD_POSTINIT,
        RD_DLACTIVITY
} rd_event_e;
 
/*
 * ways that the event notification can take place:
 */
typedef enum {
        RD_NOTIFY_BPT,
        RD_NOTIFY_AUTOBPT,
        RD_NOTIFY_SYSCALL
} rd_notify_e;
 
/*
 * information on ways that the event notification can take place:
 */
typedef struct rd_notify {
        rd_notify_e     type;
        union {
                psaddr_t        bptaddr;
                long            syscallno;
        } u;
} rd_notify_t;
rd_event_enable() 

rd_err_e rd_event_enable(struct rd_agent * rdap, int onoff);

この関数は、イベント監視を有効 (1) または無効 (0) にします。

注 -

パフォーマンス上の理由から、現在、実行時リンカーはイベントの無効化を無視します。制御プロセスは、このルーチンへの最後の呼び出しが原因で指定のブレークポイントに到達しないと、想定することはできません。

rd_event_addr() 

rd_err_e rd_event_addr(rd_agent_t * rdap, rd_event_e event,
        rd_notify_t * notify);

この関数は、制御プログラムへの指定イベントの通知方法を指定します。

イベントタイプに従って、制御プロセスの通知は、notify->u.syscallno で特定されるチープなシステム呼び出しを呼び出すか、または notify->u.bptaddr によって指定されたアドレスでブレークポイントを実行することで行われます。システム呼び出しの追跡または実際のブレークポイントの設定は、制御プロセスが行う必要があります。

イベントが発生した場合は、rtld_db.h に定義された次のインタフェースによって追加情報を取得できます。


typedef enum {
        RD_NOSTATE = 0,
        RD_CONSISTENT,
        RD_ADD,
        RD_DELETE
} rd_state_e;
 
typedef struct rd_event_msg {
        rd_event_e      type;
        union {
                rd_state_e      state;
        } u;
} rd_event_msg_t;

rd_state_e 値の意味は次のとおりです。

RD_NOSTATE

使用可能な追加状態情報なし

RD_CONSISTANT

リンクマップは安定した状態にあってテスト可能

RD_ADD

動的オブジェクトは削除処理中であり、リンクマップは安定した状態にない。リンクマップは、RD_CONSISTANT 状態に達するまでテストできない

RD_DELETE

動的オブジェクトは削除処理中であり、リンクマップは安定した状態にない。リンクマップは、RD_CONSISTANT 状態に達するまでテストできない

rd_event_getmsg() 

rd_err_e rd_event_getmsg(struct rd_agent * rdap, rd_event_msg_t * msg);

この関数は、イベントに関する追加情報を提供します。

次の表は、異なる各イベントタイプで可能な状態を示しています。

RD_PREINIT

RD_POSTINIT

RD_DLACTIVITY

RD_NOSTATE

RD_NOSTATE

RD_CONSISTANT

 

 

RD_ADD

 

 

RD_DELETE

手続きリンクテーブルのスキップ

rtld-デバッガインタフェースは、手続きリンクのテーブルエントリをスキップオーバーするための機能を提供します (「手続きリンクテーブル (プロセッサに固有)」を参照)。デバッガなどの制御プロセスは、初めて関数に介入するよう要求される場合、実際の手続きリンクテーブル処理をスキップしようとします。この結果、制御は、関数定義を検索するために実行時リンカーに渡されます。

次のインタフェースを使用すると、制御プロセスで実行時リンカーの手続きリンクテーブル処理にステップオーバーできます。制御プロセスは、ELF ファイルで提供される外部情報に基づいて、手続きリンクのテーブルエントリに遭遇する時期を判定できるものと想定されます。

ターゲットプロセスは、手続きリンクのテーブルエントリに介入すると、次のインタフェースを呼び出します。

rd_plt_resolution() 

rd_err_e rd_plt_resolution(rd_agent_t * rdap, paddr_t pc,
        lwpid_t lwpid, paddr_t plt_base, rd_plt_info_t * rpi);

この関数は、現在の手続きリンクテーブルエントリの解決状態と、それをスキップする方法に関する情報を返します。

pc は、手続きリンクテーブルエントリの最初の命令を表します。lwpid は lwp 識別子を提供し、plt_base は手続きリンクテーブルの基本アドレスを提供します。これらの 3 つの変数は、各種のアーキテクチャが手続きリンクテーブルを処理するため十分な情報を提供します。

rpi は、次のデータ構造 (rtld_db.h に定義) に定義された、手続きリンクのテーブルエントリに関する詳しい情報を提供します。


typedef enum {
    RD_RESOLVE_NONE,
    RD_RESOLVE_STEP,
    RD_RESOLVE_TARGET,
    RD_RESOLVE_TARGET_STEP
} rd_skip_e;
 
typedef struct rd_plt_info {
        rd_skip_e       pi_skip_method;
        long            pi_nstep;
        psaddr_t        pi_target;
} rd_plt_info_t;

次のシナリオは rd_plt_info_t 戻り値から考えられます。

注 -

今後の実装状態では、ターゲット関数にブレークポイントを直接設定する方法として、RD_RESOLVE_TARGET を使用する可能性がありますが、この機能は、今回のバージョンの rtld-デバッガインタフェースではまだ使用できません。

動的オブジェクトのパッド

実行時リンカーのデフォルト動作は、オペレーティングシステムに依存して、最も効率的に参照できる場所に動的オブジェクトを読み込みます。制御プロセスの中には、ターゲットプロセスのメモリーに読み込まれたオブジェクトの周りにパッドがあることによって、利益を受けるものがあります。このインタフェースを使用すると、制御プロセスは、このパッドを要求できます。

rd_objpad_enable() 

rd_err_e rd_objpad_enable(struct rd_agent * rdap, size_t padsize);

この関数は、ターゲットプロセスによって続けて読み込まれたオブジェクトのパッドを有効または無効にします。パッドは読み込まれたオブジェクトの両側で行われます。

padsize は、メモリーに読み込まれたオブジェクトの前後両方で維持されるパッドのサイズをバイト数で指定します。このパッドは、mmap(2) に PROT_NONE 権と MAP_NORESERVE フラグをつけて使用して、メモリー割り当てとして予約できます。実行時リンカーは、割り当てられたオブジェクトに隣接するターゲットプロセスの仮想アドレス空間の領域を効果的に予約します。これらの領域は、制御プロセスによって後に利用できます。

padsize を 0 にすると、後のオブジェクトに対するオブジェクトパッドは無効になります。

注 -

mmap(2) を /dev/zero から、MAP_NORESERVE によって使用して取得される予約は、proc(1) 機能を使用して、rd_loadobj_t に提供されたリンクマップ情報を参照することによって報告できます。

デバッガインポートインタフェース

制御プロセスが librtld_db.so.1 に対して提供しなければならないインポートインタフェースは、/usr/include/proc_service.h に定義されています。これらの proc_service 関数のサンプル実装状態は、rdb デモデバッガにあります。rtld-デバッガインタフェースは、使用可能な proc_service インタフェースのサブセットだけを使用します。rtld-デバッガインタフェースの今後のバージョンでは、互換性のない変更を作成することなく、追加 proc_service インタフェースを利用できる可能性があります。

次のインタフェースは、現在、rtld-デバッガインタフェースによって使用されています。

ps_pauxv() 

ps_err_e ps_pauxv(const struct ps_prochandle * ph, auxv_t ** aux);

この関数は、auxv ベクトルのコピーへのポインタを返します。auxv ベクトル情報は、割り当てられた構造にコピーされるため、このポインタの存続期間は、ps_prochandle が有効な間になります。

ps_pread() 

ps_err_e ps_pread(const struct ps_prochandle * ph, paddr_t addr,
        char * buf, int size);

この関数は、アドレス addr にあるターゲットプロセスからサイズバイトを読み取って、それらを buf にコピーします。

ps_pwrite() 

ps_err_e ps_pwrite(const struct ps_prochandle * ph, paddr_t addr,
          char * buf, int size);

この関数は、サイズバイトを buf から、アドレス addr にあるターゲットプロセスに書き込みます。

ps_plog() 

void ps_plog(const char * fmt, ...);

この関数は、rtld-デバッガインタフェースから追加診断情報によって呼び出されます。この診断情報をどこに記録するか、または記録するかどうかは、制御プロセスが決める必要があります。ps_plog() の引数は、printf(3C) 形式に従っています。

ps_pglobal_lookup() 

ps_err_e ps_pglobal_lookup(const struct ps_prochandle * ph,
        const char * obj, const char * name, ulong_t * sym_addr);

この関数は、ターゲットプロセス ph 内のオブジェクト obj 内の記号 name を検索します。記号が検出されると、記号のアドレスが sym_addr に保存されます。

ps_pglobal_sym() 

ps_err_e ps_pglobal_sym(const struct ps_prochandle * ph,
        const char * obj, const char * name, ps_sym_t * sym);

この関数は、ターゲットプロセス ph 内のオブジェクト obj 内の記号 name を検索します。記号が検出されると、記述子 sym は埋められます。

rtld-デバッガインタフェースがアプリケーションまたは実行時リンカー内の記号を検出してから、リンクマップを作成する必要があるイベントでは、obj に対する次の予約値を使用できます。


#define PS_OBJ_EXEC ((const char *)0x0)  /* application id */
#define PS_OBJ_LDSO ((const char *)0x1)  /* runtime linker id */

制御プロセスがこれらのオブジェクトの記号テーブルを検出するために使用できる機構の 1 つに、次の擬似コードを使用する procfs ファイルシステムを介するものがあります。


ioctl(.., PIOCNAUXV, ...)       - obtain AUX vectors
ldsoaddr = auxv[AT_BASE];
ldsofd = ioctl(..., PIOCOPENM, &ldsoaddr);
 
/* process elf information found in ldsofd ... */
 
execfd = ioctl(.., PIOCOPENM, 0);
 
/* process elf information found in execfd ... */

ファイル記述子が見つかったら、ELF ファイルは、制御プログラムによってその記号情報をテストできます。