このセクションでは、/usr/lib/librtld_db.so.1 監査ライブラリによってエクスポートされる各インタフェースについて説明します。この節は、機能グループごとに分けられています。
rd_err_e rd_init(int version); |
この関数は、rtld-デバッガバージョン条件を確立します。ベースとなるバージョンは、RD_VERSION1 として定義されています。現在の「バージョン」は常に RD_VERSION で定義されます。
Solaris 8 10/00 で追加されたバージョン RD_VERSION2 は、rd_loadobj_t 構造体を拡張するものです (「読み込み可能オブジェクトの走査」の rl_flags、rl_bend、rl_dynamic の各フィールドを参照)。
Solaris 8 1/01 で追加されたバージョン RD_VERSION3 は、rd_plt_info_t 構造体を拡張するものです (「プロシージャのリンクテーブルのスキップ」 の pi_baddr および pi_flags の各フィールドを参照)。
制御プロセスのバージョン条件が使用可能な rtld-デバッガインタフェースよりも大きい場合は、RD_NOCAPAB が返されます。
rd_agent_t * rd_new(struct ps_prochandle * php); |
この関数は、新しいエクスポートのインタフェースエージェントを作成します。「php」は、制御プロセスによってターゲットプロセスを特定するために作成された cookie です。この cookie は、制御プロセスによってコンテキストを維持するために提供される重要なインタフェースで使用されるものであり、rtld-デバッガインタフェースに対して不透明です。
rd_err_e rd_reset(struct rd_agent * rdap); |
この関数は、rd_new() に指定された同じ ps_prochandle 構造に基づくエージェント内の情報をリセットします。この関数は、ターゲットプロセスが再スタートされると呼び出されます。
次のエラー状態は、rtld-デバッガインタフェース (rtld_db.h に定義) によって返されます。
typedef enum { RD_ERR, RD_OK, RD_NOCAPAB, RD_DBERR, RD_NOBASE, RD_NODYNAM, RD_NOMAPS } rd_err_e; |
次のインタフェースは、エラー情報を収集するために使用できます。
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; psaddt_t rl_dynamic; } rd_loadobj_t; |
文字列ポインタを含めて、この構造で指定されるアドレスはすべてターゲットプロセス内のアドレスであり、制御プロセス自体のアドレス空間のアドレスでないことに注意してください。
動的オブジェクトの名前を含む文字列へのポインタ
リビジョン RD_VERSION2 では、動的に読み込まれる再配置可能オブジェクトは RD_FLG_MEM_OBJECT で識別されます。
動的オブジェクトの基本アドレス
動的オブジェクトのデータセグメントの基本アドレス
リンクマップ識別子 (「名前空間の確立」を参照)
動的オブジェクトがフィルタの場合は (「フィルタとしての共有オブジェクト」を参照)、フィルティーの名前を指定する
これらの要素は、下方互換性のために存在するものであり、現在は使用されていない
オブジェクトのエンドアドレス (text + data + bss)。リビジョン RD_VERSION2 では、動的に読み込まれる再配置可能オブジェクトの場合、この要素は作成されたオブジェクトの最後を指します。このオブジェクトには、自身のセクションヘッダーが含まれています。
動的オブジェクト前のパッドの基本アドレス (「動的オブジェクトのパッド」を参照)
動的オブジェクト後のパッドの基本アドレス (「動的オブジェクトのパッド」を参照)
このフィールドは RD_VERSION2 に追加されたもので、DT_CHECKSUM (表 7-43 を参照) のエントリへのリファレンスを可能にするオブジェクトの動的セクションのベースアドレスを提供します。
次のルーチンは、このオブジェクトデータ構造を使用して実行時リンカーリンクマップリストの情報にアクセスしています。
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 が返される場合、実行時リンカーは、まだ初期リンクマップを読み込みません。
実行時リンカーの適用範囲内で発生し、制御プロセスが追跡できる特定のイベントがあります。これらのイベントは次のとおりです。
実行時リンカーは、すべての動的オブジェクトを読み込んで再配置し、読み込まれた各オブジェクトの .init セクションの呼び出しを開始 (「デバッギングエイド」を参照)。
実行時リンカーは、すべての .init セクションの呼び出しを終了して、基本実行可能ファイルに制御を渡す。
実行時リンカーは、動的オブジェクトを読み込みまたは読み込み解除のために呼び出される (「追加オブジェクトの読み込み」を参照)。
これらのイベントは、次のインタフェース (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_err_e rd_event_enable(struct rd_agent * rdap, int onoff); |
パフォーマンス上の理由から、現在、実行時リンカーはイベントの無効化を無視します。制御プロセスは、このルーチンへの最後の呼び出しが原因で指定のブレークポイントに到達しないと、想定することはできません。
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_CONSISTANT 状態に達するまでテストできない
動的オブジェクトは削除処理中であり、リンクマップは安定した状態にない。リンクマップは、RD_CONSISTANT 状態に達するまでテストできない
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_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; psaddr_t pi_baddr; unsigned int pi_flags; } rd_plt_info_t; #define RD_FLG_PI_PLTBOUND 0x0001 |
プロシージャのリンクテーブルエントリがどのように扱われるかを示す。rd_skip_e 値内の 1 つに設定される
RD_RESOLVE_STEP または RD_RESOLVE_TARGET_STEP が返された時にステップオーバーする命令がいくつあるかを示す
RD_RESOLVE_TARGET_STEP または RD_RESOLVE_TARGET が返された時にブレークポイントを設定するアドレス指定する
RD_VERSION3 で追加された、プロシージャのリンクテーブルの宛先アドレス。pi_flags フィールドの RD_FLG_PI_PLTBOUND フラグが設定されると、この要素は解決された (結合された) 宛先アドレスを示す
RD_VERSION3 で追加されたフラグフィールド。フラグ RD_FLG_PI_PLTBOUND は、pi_baddr フィールドで取得できる宛先アドレスへ解決された (結合された) プロシージャのリンクエントリを示す
次のシナリオは rd_plt_info_t 戻り値から考えられます。
これはこのプロシージャのリンクテーブルで最初の呼び出しであるため、実行時リンカーによって解決する必要がある。rd_plt_info_t には、次のものが含まれる
{RD_RESOLVE_TARGET_STEP, M, <BREAK>, 0, 0} |
制御プロセスは、BREAK にブレークポイントを設定し、ターゲットプロセスを続けます。ブレークポイントに達すると、プロシージャのリンクのテーブルエントリ処理は終了し、制御プロセスは M 命令を宛先関数にステップできます。これはプロシージャのリンクテーブルエントリで最初の呼び出しであるため、結合アドレス (pi_baddr) が設定されていないことに注意してください。
このプロシージャのリンクテーブル全体で N 番目。rd_plt_info_t には、次のものが含まれる
{RD_RESOLVE_STEP, M, 0, <BoundAddr>, RD_FLG_PI_PLTBOUND} |
プロシージャのリンクのテーブルエントリはすでに解決されていて、制御プロセスは M 命令を宛先関数にステップできます。プロシージャのリンクテーブルエントリが結合されるアドレスは <BoundAddr> で、RD_FLG_PI_PLTBOUND ビットが flags フィールドに設定されています。
今後の実装状態では、ターゲット関数にブレークポイントを直接設定する方法として、RD_RESOLVE_TARGET を使用する可能性がありますが、この機能は、今回のバージョンの rtld-デバッガインタフェースではまだ使用できません。
実行時リンカーのデフォルト動作は、オペレーティングシステムに依存して、最も効率的に参照できる場所に動的オブジェクトを読み込みます。制御プロセスの中には、ターゲットプロセスのメモリーに読み込まれたオブジェクトの周りにパッドがあることによって、利益を受けるものがあります。このインタフェースを使用すると、制御プロセスは、このパッドを要求できます。
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 に提供されたリンクマップ情報を参照することによって報告できます。