| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
マニュアルページセクション 1: ユーザーコマンド Oracle Solaris 11.1 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
マニュアルページセクション 1: ユーザーコマンド Oracle Solaris 11.1 Information Library (日本語) |
- 動的オブジェクト用の実行時リンカー
/lib/ld.so.1
/lib/ld.so.1 [-e envar] dynamic-object [object args]...
動的アプリケーションは、1 つ以上の動的オブジェクトで構成されています。動的アプリケーションとは、通常、1 つの動的実行可能ファイルと 1 つ以上の共有オブジェクト依存関係のことです。動的アプリケーションの初期化と実行の一部として、「インタプリタ」が呼び出されます。このインタプリタは、アプリケーションをその共有オブジェクト依存関係に結合する作業を完了させます。Solaris では、このインタプリタを実行時リンカーと呼びます。
動的実行可能ファイルのリンク編集中は、特別な .interp セクションが、関連のプログラムヘッダーとともに作成されます。このセクションには、プログラムのインタプリタを指定するパス名が組み込まれています。インタプリタのパス名は、-I オプションを ld(1) (リンカー) に使用して実行可能ファイルが作成される場合に指定できます。リンカーによって提供されるデフォルトの名前は、実行時リンカーの名前 ld.so.1 です。
動的実行可能ファイルの実行プロセスの間は、カーネルがファイルをマッピングし、必要なインタプリタを見つけ出します。exec(2) and mmapobj(2)を参照してください。カーネルはこのインタプリタ内でマッピングを行い、このインタプリタに制御を渡します。十分が情報がインタプリタに渡されるため、インタプリタは引き続きアプリケーションを結合および実行できます。
アプリケーションの初期化に加え、実行時リンカーは、アプリケーションが自分のアドレス空間を拡張できるサービスを使用できるようにするサービスも提供します。追加の共有オブジェクトがマッピングされ、共有オブジェクト内のシンボルが結合できるようになります。
実行時リンカーは次の関数を実行します。
構成ファイルが存在する場合は、そのファイルが処理されます。構成ファイルは、デフォルト検索パスの変更に使用されます。また、ディレクトリキャッシュや代替オブジェクトの依存関係を提供します。crle(1) のマニュアルページを参照してください。デフォルトでは、32 ビットオブジェクトの場合には、構成ファイル /var/ld/ld.config が使用されます。64 ビットオブジェクトの場合には、デフォルトの構成ファイル /var/ld/64/ld.config が使用されます。代替の構成ファイルは、LD_CONFIG 環境変数で指定できます。また、代替の構成ファイルは、ld(1) の -c オプションを使用すると、動的実行可能ファイル内にもエンコードできます。
実行時リンカーは、アプリケーションの動的な情報セクション .dynamic を分析し、どの共有オブジェクト依存関係が必要になるかを判断します。
次に、実行時リンカーはこれらの依存関係を検索し、マッピングします。その後、各依存関係の動的な情報セクションを分析し、さらに依存関係が必要かどうかを判断します。
共有オブジェクトの依存関係がすべて読み込まれると、実行時リンカーは必要な再配置をすべて行います。これらの再配置により、実行プロセスに備えて共有オブジェクトが結合されます。
共有オブジェクトの依存関係 (場合によっては、動的実行可能ファイル) によって提供された初期化関数がすべて呼び出されます。関数は、位相的にソートされた依存関係とは逆の順序で呼び出されます。循環型依存関係が存在すると、初期化関数は循環が排除されたソート順序で呼び出されます。ldd(1) を使用すると、共有オブジェクトの依存関係の初期化順序を表示できます。
アプリケーションに制御が引き渡されます。
アプリケーションの実行中は、実行時リンカーを呼び出すことで、遅延関数結合を実行できます。
共有オブジェクトがプロセスから削除されると、終了関数が呼び出されます。デフォルトでは、これらの関数は、位相的にソートされた依存関係の順序で呼び出されます。
アプリケーションは、実行時リンカーのサービスを呼び出し、dlopen(3C) を使用して追加の共有オブジェクトを取得することもできます。これらのオブジェクトによって提供されるシンボルは、dlsym(3C) を使用して結合できます。
以前の各項目の詳細については、『リンカーとライブラリ』にあります。
実行時リンカーは、指定した検索パスを使って、オブジェクトの動的な依存関係を検索します。デフォルトの検索パスは、オブジェクト内に記録された runpath と、それに続く一連のデフォルトのパスです。32 ビットオブジェクトの場合、デフォルトは、順番に、/lib、そして /usr/lib です。64 ビットオブジェクトの場合、デフォルトは、順番に /lib/64、そして /usr/lib/64 です。これらのデフォルトのコンポーネントは、crle(1) で作成された構成ファイルを使用して変更できます。runpath は、-R オプションを ld(1) に使用して動的オブジェクトを作成する場合に指定されます。環境変数 LD_LIBRARY_PATH は、デフォルトのディレクトリの前に検索されるディレクトリを指定するために使用できます。
通常、実行時リンカーは、実行時リンカーをインタプリタとして宣言した動的実行可能ファイルを実行することで間接的に呼び出されます。また、実行時リンカーはコマンド行から直接実行できます。このメカニズムは、実行時リンカーの新規実装を試す場合によく使用されます。コマンド行で指定された引数は、実行時リンカーに適用可能なオプションで構成されます。これらのオプションのあとには、実行する動的オブジェクトの名前とそのオブジェクトで必要なオプションが続きます。事実上、実行時リンカーは、動的オブジェクトによって指定されたすべてのインタプリタを置き換えます。
次のオプションがサポートされています。
実行時リンカー固有の環境変数を指定します。「環境変数」の節を参照してください。このオプションを使用する変数セットは、すべての環境変数、または同名の構成ファイル変数よりも優先されます。変数 LD_NOENVIRON は、-e オプションの処理後に処理すべき環境変数がないことを示すために指定できます。
各環境変数には、_32 または _64 という接尾辞を指定できます。この接尾辞は、環境変数をそれぞれ 32 ビットまたは 64 ビットプロセス固有のものにします。この環境変数は、接尾辞の付いてない環境変数が有効な場合でも、それに優先します。値なしに指定された環境変数で、_32 または _64 の接尾辞が付いている場合は、事実上、関連する汎用の環境変数設定が取り消されます。
コロンで区切られたオブジェクトの一覧が実行時リンカーによって読み込まれます。各オブジェクトが読み込まれると、そのオブジェクトは Link-Auditing インタフェースルーチンがないかどうか検査されます。存在するルーチンは、『リンカーとライブラリ』で説明されている Link-Auditing インタフェースで指定されているとおりに呼び出されます。ld(1) の -p および -P オプションも参照してください。
実行時リンカーがレイジー結合を実行するデフォルトのモードは、環境変数 LD_BIND_LAZY を NULL 以外の任意の値に指定することで、強制的に設定できます。この設定により、実行時リンカーは、プロセスに読み込まれたすべてのオブジェクトに対してレイジー参照再配置のみを実行します。個々のオブジェクトは、オブジェクトの読み込み時にレイジー参照再配置を実行するように要求できます。ld(1) の -z now オプションおよび RTLD_NOW モードの dlopen(3C) を参照してください。LD_BIND_LAZY が有効になっている場合、レイジー参照再配置の実行要求は抑制されます。
LD_BIND_LAZY と LD_BIND_NOW が両方とも指定されている場合は、LD_BIND_NOW が優先されます。
実行時リンカーがレイジー結合を実行するデフォルトのモードは、環境変数 LD_BIND_NOW を NULL 以外の任意の値に指定することで、強制的に設定できます。この設定により、実行時リンカーは、プロセスに読み込まれたすべての遅延のないオブジェクトに対して即時参照とレイジー参照の両方の再配置を実行します。個々のオブジェクトは、オブジェクトの読み込み時に遅延のないレイジー参照再配置を実行するように要求できます。ld(1) の -z now オプションおよび RTLD_NOW モードの dlopen(3C) を参照してください。遅延依存関係は、LD_BIND_NOW および RTLD_NOW の影響を受けません。ld(1) の -z deferred オプションを参照してください。
LD_BIND_NOW と LD_BIND_LAZY が両方とも指定されている場合は、LD_BIND_NOW が優先されます。
すべての代替機能に対して検証すべきコンマ区切りのファイル一覧を識別します。LD_PLATCAP、LD_MACHCAP、LD_HWCAP、および LD_SFCAP。
代替構成ファイルを提供します。構成ファイルは、デフォルト検索パスの変更に使用されます。また、ディレクトリキャッシュや代替オブジェクトの依存関係を提供します。crle(1) のマニュアルページを参照してください。
コンマまたはコロン区切りのトークン一覧を提供し、実行時リンカーがデバッグ情報を標準エラーに出力するようにします。help は、使用可能なトークンをすべて指定した場合と同じ意味を持つ特殊なトークンです。環境変数 LD_DEBUG_OUTPUT は、デバッグ情報の送信先となるファイルを指定するためにも与えられます。ファイル名の末尾には、デバッグ情報を生成するアプリケーションのプロセス ID が付けられます。lari(1)を参照してください。
診断メッセージの一部として使用されるシンボル名はすべて、ELF ファイル内で定義されたとおりに表示されます。LD_DEMANGLE が NULL 以外の値に設定された場合、実行時リンカーはすべての C++ シンボル名をデコード (復号化) しようとします。
環境変数情報を与える代替手段を提供します。LD_XXX 環境変数はすべて、xxx トークンとして指定できます。トークンが複数ある場合は、コンマで区切って指定できます。「使用例」を参照してください。
代替ハードウェア機能の値を識別します。
LD_HWCAP=[+-]{token | number},....接頭辞 "+" を付けると、その機能が代替機能に追加されます。接頭辞 "-" を付けると、その機能が代替機能から削除されます。"+-" がない場合は、その機能が代替機能を置き換えます。
LD_LIBRARY_PATH 環境変数が設定されている場合、この変数は、実行時リンカーが動的依存関係を探すために使用する検索パスの拡張に使用されます。LD_LIBRARY_PATH は、デフォルトのディレクトリの前に検索されるディレクトリのコンマ区切りの一覧を指定します。LD_LIBRARY_PATH は、ld(1) にセマンティクスを追加します。
フィルタは共有オブジェクト形式です。フィルタは、実行時に代替の共有オブジェクトを選択できるようにして、フィルタ内で定義されるシンボルに実装を提供します。ld(1) の -f および -F オプションを参照してください。デフォルトでは、フィルタに対してシンボル解決が発生するまで代替共有オブジェクト処理は延期されます。LD_LOADFLTR が NULL 以外の値に設定されている場合、どのフィルタも読み込まれるとただちに処理されます。ld(1) の -z loadfltr オプションも参照してください。
代替マシンハードウェアの名前を識別します。
ローカル監査ライブラリは、アプリケーションと共有オブジェクト内で定義できます。ld(1) の -p および -P オプションを参照してください。LD_NOAUDIT が NULL 以外の値に設定されている場合、実行時リンカーはローカルの監査ライブラリをすべて無視します。
補助フィルタは共有オブジェクト形式です。補助フィルタは、実行時に代替の共有オブジェクトを選択できるようにして、フィルタ内で定義されるシンボルに実装を提供します。ld(1) の -f オプションを参照してください。LD_NOAUXFLTR が NULL 以外の値が設定されている場合、実行時リンカーはこの代替共有オブジェクトの検索を無効にします。
デフォルトでは、実行時リンカーは構成ファイルを開いて処理しようとします。LD_NOCONFIG が NULL 以外の値に設定されている場合、実行時リンカーはこの構成ファイル処理を無効にします。
構成ファイル内で提供されるすべてのディレクトリキャッシュ情報は無視されるため、LD_NOCONFIG のサブセットを提供します。
直接結合情報は、実行時リンカーに関連オブジェクト内のシンボルを直接検索するように指示します。ld(1) の -B direct オプションを参照してください。直接結合がない場合、実行時リンカーによって実行されるシンボル検索はデフォルトのモデルに従います。LD_NODIRECT が NULL 以外の値に設定されている場合、実行時リンカーは直接結合情報をすべて無視します。
構成ファイル内で提供されるすべての環境変数は無視されるため、LD_NOCONFIG のサブセットを提供します。
レイジー読み込みとラベル付けされている依存関係は、その依存関係への明示的な参照が作成されるまでメモリーに読み込まれません。ld(1) の -z lazyload オプションを参照してください。LD_NOLAZYLOAD が NULL 以外の値に設定されている場合、実行時リンカーは依存関係のレイジー読み込みのラベルを無視し、その依存関係をただちに読み込みます。
構成ファイル内で提供されるすべての代替オブジェクト依存関係は無視されるため、 LD_NOCONFIG のサブセットを提供します。
デフォルトでは、実行時リンカーは、プライマリ実行可能ファイルおよびそのすべての依存関係についてバージョンの依存関係を検証します。LD_NOVERSION が NULL 以外の値が設定されている場合、実行時リンカーはこのバージョンチェックを無効にします。
$ORIGIN の即時処理は、環境変数 LD_ORIGIN を NULL 以外の値に設定することによって開始できます。Solaris 9 より前のバージョンでは、このオプションは、$ORIGIN 文字列トークンを使用する依存関係を検索する前にchdir(2) を呼び出すアプリケーションにとって便利なオプションでした。現在では、デフォルトで実行時リンカーが現在の作業用ディレクトリを作成するため、このオプションは不要です。
代替プラットフォームの名前を識別します。
スペース区切りの共有オブジェクトの一覧を提供します。これらのオブジェクトは、実行されるプログラムのあとに読み込まれますが、そのプログラムが参照するほかの共有オブジェクトより早く読み込まれます。事前に読み込まれたオブジェクトによって提供されるシンボル定義は、プログラムが参照する共有オブジェクトによって作成された参照に挿入されます。事前に読み込まれたオブジェクトによって提供されるシンボル定義は、プログラムによって提供されるシンボル定義には挿入されません。
実行時リンカーによってプロファイルが作成される共有オブジェクトを定義します。プロファイルの作成が有効な場合、プロファイリングバッファーファイルが作成され、マッピングされます。バッファーファイル名はプロファイルが作成される共有オブジェクトの名前で、拡張子は .profile となります。デフォルトでは、このバッファーは /var/tmp の下に置かれます。また、環境変数 LD_PROFILE_OUTPUT が、プロファイリングバッファーを置く代替ディレクトリを示すために設定されます。
プロファイリングバッファーには、profil(2) と呼び出し回数情報が含まれます。この情報は、cc の -xpg オプションにリンクされたプログラムによって生成される gmon.out 情報と同様です。指定された共有オブジェクトを使用し、この環境変数が設定されているときに動作するアプリケーションはすべて、プロファイルバッファーにデータを蓄積します。「注意事項」も参照してください。プロファイルバッファー情報は、gprof(1) を使用して検査できます。
LD_PROFILE によるプロファイル作成方法は、コンパイルシステムによって提供されることがあるほかの方法の代替手段です。プロファイルが作成される共有オブジェクトでは設定を行う必要はまったくなく、LD_PROFILE をプロファイルが設定されているアプリケーションと組み合わせてはいけません。共有オブジェクトのプロファイル作成について詳しくは、『リンカーとライブラリ』を参照してください。
代替ソフトウェア機能の値を識別します。
LD_SFCAP=[+-]{token | number},....接頭辞 "+" を付けると、その機能が代替機能に追加されます。接頭辞 "-" を付けると、その機能が代替機能から削除されます。"+-" がない場合は、その機能が代替機能を置き換えます。
致命的な実行時エラーの発生時に、実行時リンカーがプロセスを強制終了するために使用する「数値」シグナル番号を提供します。thr_kill(3C)を参照してください。デフォルトでは、SIGKILL が使用されます。たとえば、代替シグナル番号が 6 (SIGABRT) の場合、デバッグを支援するコアファイルを作成できます。dlinfo(3C) への RTLD_DI_SETSIGNAL 要求も参照してください。
文字列 'LD_' で始まる環境変数名は、ld(1) と ld.so.1 の拡張用として予約されています。
セキュリティー保護されたプロセスでは、悪意のある依存関係の置換またはシンボルの割り込みを防ぐため、依存関係と runpath の評価にいくつかの制約があります。
実行時リンカーは、issetugid(2) システム呼び出しがプロセスに対して true を返した場合、そのプロセスを安全と分類します。
32 ビットオブジェクトの場合、実行時リンカーが認識しているデフォルトのトラストディレクトリは、/lib/secure/ と /usr/lib/secure/ です。64 ビットオブジェクトの場合、デフォルトのトラストディレクトリは /lib/secure/64 と /usr/lib/secure/64 です。ユーティリティー crle(1) を使用すれば、セキュリティー保護されたアプリケーション向けに追加のトラストディレクトリを指定できます。この方法を使用する場合には、管理者は、ターゲットディレクトリを悪意のある侵入から適切に保護する必要があります。
あるセキュリティー保護されたプロセスに対して LD_LIBRARY_PATH ファミリ環境変数が有効になっている場合、実行時リンカーの検索規則を拡張するために使用されるのは、この変数に指定された「トラスト」ディレクトリだけです。
セキュリティー保護されたプロセスでは、アプリケーションまたはその依存関係のいずれかによって提供される runpath コンポーネントは、そのコンポーネントがフルパス名 (つまり、'/' で始まるパス名) である場合に使用されます。
セキュリティー保護されたプロセスでは、$ORIGIN 文字列の拡張は、その文字列がトラストディレクトリに拡張されるときに限り許可されます。ただし、$ORIGIN を展開することですでに依存関係を提供したディレクトリに一致する場合、そのディレクトリは暗黙にセキュリティー保護されます。このディレクトリは、追加の依存関係を提供するために使用できます。
セキュリティー保護されたプロセスでは、LD_CONFIG は無視されます。ただし、セキュリティー保護されたアプリケーションで記録された構成ファイルは使用されます。ld(1) の -c オプションを参照してください。記録される構成ファイルは、フルパス名 (つまり、'/' で始まるパス名) にする必要があります。記録される構成ファイルが $ORIGIN 文字列を使用する場合、そのファイルは既知のトラストディレクトリに制限されます。セキュリティー保護されたアプリケーション内の構成ファイルを記録する開発者は、構成ファイルディレクトリを悪意のある侵入から適切に保護する必要があります。記録された構成ファイルがない場合、セキュリティー保護されたプロセスは、構成ファイルがあれば、デフォルトの構成ファイルを使用します。crle(1) を参照してください。
セキュリティー保護されたプロセスでは、LD_SIGNAL は無視されます。
追加のオブジェクトは、LD_PRELOAD または LD_AUDIT 環境変数を使用すると、セキュリティー保護されたプロセスで読み込むことができます。これらのオブジェクトは「フル」パス名または「単純」ファイル名で指定しなければなりません。フルパス名は、既知の「トラスト」ディレクトリに限定されます。単純ファイル名 (名前に '/' が付いていない) は、前述した検索パスの制約に従って配置されます。単純ファイル名は、既知の「トラスト」ディレクトリにのみ解決されることになります。
セキュリティー保護されたプロセスでは、単純ファイル名を構成する依存関係は、前述のパス名の制約を使用して処理されます。フルパス名または相対パス名で表示された依存関係は、そのまま使用されます。したがって、セキュリティー保護されたプロセスの開発者は、フルパス名または相対パス名依存関係として参照されるターゲットディレクトリを悪意のある侵入から適切に保護する必要があります。
セキュリティー保護されたプロセスを作成する場合、依存関係を表したり、dlopen(3C) パス名を作成したりするために相対パス名を使用してはいけません。この制約は、アプリケーションと「すべての」依存関係に適用するようにしてください。
例 1 LD_FLAGS のグループ環境変数情報への使用
LD_FLAGS の次の使用法は、環境変数 LD_BIND_NOW と LD_LIBRARY_PATH をそれぞれ 32 ビットアプリケーション用に設定することと同等です。
example% LD_FLAGS_32=bind_now,library_path=/lib/one:/lib/two
LD_FLAGS の次の使用法は、環境変数 LD_LIBRARY_PATH と LD_PRELOAD をそれぞれ 64 ビットアプリケーション用に設定することと同等です。
example% LD_FLAGS_64=library_path=/lib/one/64,preload=foo.so
デフォルトの実行時リンカー。
SVID ABI 互換性のための代替インタプリタ
NULL 文字ポインタをサポートする互換性ライブラリ。「注意事項」を参照してください。
セキュリティー保護されたアプリケーション用の LD_PRELOAD の位置。
セキュリティー保護された 64 ビットアプリケーション用の LD_PRELOAD の位置。
64 ビットアプリケーション用のデフォルトの実行時リンカー。
NULL 文字ポインタをサポートする 64 ビット互換性ライブラリ。「注意事項」を参照してください。
32 ビットアプリケーション用のデフォルトの構成ファイル。
64 ビットアプリケーション用のデフォルトの構成ファイル。
属性についての詳細は、マニュアルページの attributes(5) を参照してください。
|
crle(1), gprof(1), lari(1), ld(1), ldd(1), exec(2), issetugid(2), mmapobj(2), profil(2), dladdr(3C), dlclose(3C), dldump(3C), dlerror(3C), dlinfo(3C), dlopen(3C), dlsym(3C), thr_kill(3C), proc(4), attributes(5)
LD_PROFILE を、proc(4) のユーザーなど、ほかのプロセス監視方法と組み合わせて使う場合は注意してください。プロセス監視方法が複数あると、デッドロック条件が発生してプロファイルバッファーがロックされたままになるおそれがあります。ロックされたバッファーは、プロファイル情報を記録しようとするプロセスをすべてブロックします。この問題が発生する可能性を減らすために、実行時リンカーのプロファイル実装は、起動時にプロセスが監視されているどうかを確認します。その場合、プロセスのプロファイル作成は何も出力されずに無効にされます。ただし、このメカニズムでは、このプロセスに付随する監視プロセスをプロセスの実行中に取得できません。
ユーザー互換性ライブラリ /usr/lib/0@0.so.1 では、0 の値を位置 0 で設定するメカニズムを利用できます。アプリケーションの中には、NULL 文字ポインタを NULL 文字列へのポインタと同じように処理するべきだと誤って解釈するものがあります。このようなアプリケーションでは、NULL 文字ポインタに対してアクセスがあるとセグメンテーション違反が発生します。LD_PRELOAD を使用して実行時にこのライブラリがそのようなアプリケーションに追加されると、こうした誤動作が起こりやすい環境が作られます。しかし、ユーザー互換性ライブラリは、このようなアプリケーションを生成するためのものでも、こうした特殊なプログラミング作業を奨励するためのものでもありません。
ほとんどの場合、/usr/lib/0@0.so.1 が存在していても問題はなく、これを必要としないプログラムに事前に読み込まれてもかまいません。ただし、例外があります。JVM (Java 仮想マシン) など一部のアプリケーションでは、NULL ポインタへのアクセスによってセグメント違反が発生する必要があります。JVM などのアプリケーションでは、/usr/lib/0@0.so を事前に読み込まないようにしてください。
|