問題タブ [intel-pin]

ピン ツールをコンパイルlddし、ピン ツール共有オブジェクトで実行すると、共有オブジェクト libxed.so、libpin3dwarf.so、libdl-dynamic.so、libstlport-dynamic.so、および libc-dynamic.so がすべて見つかりません。他のオブジェクト ファイルをリンクするように変更したため、makefile.rules ファイルではないかと思いましたが、pin ディレクトリにあるサンプル ピン ツールをコンパイルしても、同じ問題が発生します。誰が問題が何であるかを知っていますか？

長い投稿で申し訳ありません:)

例外で次のことを行う.exeファイル用のピンツールを作成したいと思います。

1. 例外命令アドレスを出力します。
2. この例外を処理するハンドラのアドレスを出力します。
3. プログラムが戻る命令のアドレスを出力します。

私は Windows SEH メカニズムについてすべて読んでおり、Intel ピンツール自体にも精通しています。作業を開始するために、次のテスト プログラムを作成しました。

次に、pintool を使用して、すべてのルーチン (main が呼び出された後に呼び出されるルーチン) と、このプログラムの戻りアドレスを出力しました。リストは次のとおりです。

次に、これらのルーチンのドキュメントを読みました。これらのルーチンの引数には、必要な情報が含まれている可能性があると考えました。しかし、すべて無駄です。RtlRaiseException引数によってExceptionRecord構造体にアクセスできましたが、そのExceptionAddressフィールドには のアドレスではRaiseExceptionなく の開始アドレスが含まれていますbar。

そして、を処理する例外ハンドラの場所を取得する方法を見つけることができませんでしたthrow。

どんな助けでも大歓迎です。ありがとう ：）

windows8 32 ビット、visual studio 2012、インテル pintool (76991 バージョン) を使用しています。コマンドを使用してdllを作成するために開発者コマンドプロンプトを使用しています：

エラーが発生しています：

インターネット上で、以下の理由により、このエラーが発生している可能性があることがわかりました。

リリース モードでビルドするには、どのフラグを含める必要がありますか (コマンド プロンプトを使用しているため)。

PIN_SetContextReg を使用してレジスタの値を変更しようとしています。まず、PIN_GetContextReg を old_val として使用して REG_INST_PTR の値を取得します。次に、この値に変更を加えて、new_val と同じレジスタに設定します。使用できるランダム値は何ですか。また、REG_INST_PTR 以外のどのレジスターを変更することができ、インストルメント化するプログラムに大きな影響を与えますか。

ここに方法があります

メソッドはここで呼び出されます

バイナリを計測するための pintool を作成しています。

命令に関する情報を保存するために sqlite3 データベースを使用したいと思います。

問題なく sqlite3 の "helloworld" の例をコンパイルして実行できます。同様に、sqlite 接続なしで pintool をコンパイルして実行できます。ただし、pintool に sqlite コードを統合するたびにエラーが発生します。

dlopen に失敗しました: ライブラリ "libsqlite3.so.0" が見つかりません

正確には何をしますか：

1. 私のリンクコマンドは次のようになります(コンパイルはエラーなしで終了します):

   g++ -shared -Wl,--hash-style=sysv /home/roman/Software/pin/intel64/runtime/pincrt/crtbeginS.o -Wl,-Bsymbolic -Wl,--version-script=/home/roman/ Software/pin/source/include/pin/pintool.ver -fabi-version=2 -o obj-intel64/sqliteTest.so obj-intel64/sqliteTest.o -L/home/roman/Software/pin/intel64/runtime/ pincrt -L/home/roman/Software/pin/intel64/lib -L/home/roman/Software/pin/intel64/lib-ext -L/home/roman/Software/pin/extras/xed-intel64/lib - L/usr/lib/i386-linux-gnu -lpin -lxed /home/roman/Software/pin/intel64/runtime/pincrt/crtendS.o -lpin3dwarf -ldl-dynamic -nostdlib -lstlport-dynamic -lm-dynamic - lc-動的-lsqlite3

2. LDD コマンド ldd obj-intel64/sqliteTest.so を実行すると、次の結果が得られます。

linux-vdso.so.1 => (0x00007fff4f4aa000)

libxed.so => 見つかりません

libpin3dwarf.so => 見つかりません

libdl-dynamic.so => 見つかりません

libstlport-dynamic.so => 見つかりません

libc-dynamic.so => 見つかりません

libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007fd46221f000)

libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fd462002000)

libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fd461dfe000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd461a34000)

/lib64/ld-linux-x86-64.so.2 (0x000055565d930000)

3. シンボル リンク ls -l /usr/lib/x86_64-linux-gnu/libsqlite*:

-rw-r--r-- 1 ルート ルート 1156080 2 月 22 日 17:43 /usr/lib/x86_64-linux-gnu/libsqlite3.a

-rw-r--r-- 1 ルート root 965 Feb 22 17:43 /usr/lib/x86_64-linux-gnu/libsqlite3.la

lrwxrwxrwx 1 root root 19 Feb 22 17:43 /usr/lib/x86_64-linux-gnu/libsqlite3.so -> libsqlite3.so.0.8.6

lrwxrwxrwx 1 root root 19 Feb 22 17:43 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 -> libsqlite3.so.0.8.6

-rw-r--r-- 1 ルート ルート 870240 2 月 22 日 17:43 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6

4. sqlite3 のバージョンは 3.13.0 です

5. ピンツールを実行すると、次のようになりました。

/home/roman/Software/pin/pin -t /home/roman/Software/pin/source/tools/sqliteTest/obj-intel64/sqliteTest.so -- ./test.bin

E: /home/roman/Software/pin/source/tools/sqliteTest/obj-intel64/sqliteTest.so を読み込めません: dlopen に失敗しました: ライブラリ "libsqlite3.so.0" が見つかりません

6. コードについて疑問がある場合:

   /li>

7. リンク中に -Wl および --verbose オプションを指定すると、次の情報が得られました。

/usr/lib/i386-linux-gnu/libsqlite3.so を開こうとして失敗しました

/usr/lib/i386-linux-gnu/libsqlite3.a を開こうとして失敗しました

/usr/lib/gcc/x86_64-linux-gnu/5/libsqlite3.so を開こうとして失敗しました

/usr/lib/gcc/x86_64-linux-gnu/5/libsqlite3.a を開こうとして失敗しました

/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlite3.so を開こうとすると成功しました

-lsqlite3 (/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/libsqlite3.so)

私の手のどこが悪いのか分かりますか？

どうやらピン v.3 には、私が理解できなかった外部ライブラリの特定の要件があります。ピン v.2.8 にダウングレードすると、すべて正常に動作しました。

x64 アーキテクチャ用のピン配置に付属する The Mypintool サンプルをビルドしようとしています。pin3.0 (ビルド 76991) と Visual Studio 2012 を使用しています。含まれていなければ、ビルドは成功していwindows.hます。しかし、次のようにwindow.h（別の名前空間に）含めると：-

次に、ビルドでエラーが発生します:-

windows.hまた、問題なく含まれているwin32用のツールをビルドできます。また、win32 と x64 のビルド設定を比較しましたが、相違点は見つかりませんでした。

どんな助けでも大歓迎です。

私はピン 3.0 (ビルド 76991) とビジュアル スタジオ 2012 を使用しています。ルーチン エントリをインストルメント化し、ピン ファスト バッファのエントリを埋めるために次のことを試しました。

1. イメージの計測中に必要なルーチンにRTN_InsertFillBufferを使用 しましたが、コンパイラはエラーをスローしました:RTN_InsertFillBuffer identifier not found.
2. イメージ インストルメンテーション コールバックで名前を比較して、ルーチンを見つけました。RTN_InsHead開始命令を取得するために使用されます。次に、INS_InsertFillBufferその命令に追加しました。しかし、私はsegmentation fault. PIN_DefineTraceBufferドキュメントには、スレッドの開始時にバッファーが暗黙的に割り当てられると記載されています。pin は定期的な検出を静的に実行し、イメージがインストルメント化されているときにプログラムが開始されていないため、イメージのインストルメンテーション中にバッファが割り当てられず、 を呼び出すとINS_InsertFillBufferセグメンテーション エラーが発生する可能性があります。また、画像計測で PIN_AllocateBuffer を使用してバッファーを割り当てようとしましたが、役に立ちませんでした。
3. イメージ インストルメンテーションの代わりにルーチン インストルメンテーションでステップ 2 を試みましたが、同じエラーが続きました。

では、ルーチンの開始を計測して、ピン高速バッファにエントリを追加するにはどうすればよいでしょうか?

最初の方法のコード:

インストルメンテーション コールバック:

計装:

コードまたは 2 番目の方法:

インストルメンテーション コールバック:

計装:

3番目の方法のコード:

インストルメンテーション コールバック:

計装:

PIN_GetContextReg を使用してレジスタの値を取得し、それを変更して PIN_SetContextReg を使用して元に戻したいと考えています。PIN のマニュアルには、整数レジスタでそれを行うことができると書かれていますが、REG_INST_PTR 以外のすべてのレジスタでエラーが発生します (Register ** は PIN_GetContextReg/PIN_SetContextReg ではサポートされていません)。

ここにコードがあります

この場合、レジスタ EAX を試していますが、同じエラーが発生します。ピン3.0を使用しています

実行可能ファイルとそれに関連する共有ライブラリに対して簡単なインストルメンテーション タスクを実行し、実行されたすべての命令をメイン ファイルと共有ライブラリに記録しています。

ただし、Pin必ず投げる

計装中。私は 32 ビット システムで作業しているため、約 3G のメモリ消費量に達するたびに、インストルメンテーション プロセスがクラッシュします。

このプラットフォームには非常に多くの共有ライブラリがあるため、この 32 ビット システムで作業したいと考えています。一方、実際には1つの共有ライブラリにしか興味がないため、メインの実行可能ファイルとその特別なライブラリ内で実行された命令のみを記録する方法を見つけようと考えています.

ただし、それを行うかどうか/どのように行うかはわかりません。インストルメンテーションの前の今、私の設定は次のとおりです。

ご覧のとおり、メインの実行可能ファイルを計測しているかどうかを確認していません。つまり、すべてのライブラリを計測できるはずです。

私のテスト プラットフォームは 32 ビット x86 Ubuntu 14.04 です。また、テスト対象は 32 ビット ELF バイナリ コードです。

私の質問は次のとおりです。私の状況では、メモリ例外を克服するために、関心のあるライブラリのみをインストルメント化するように構成する必要がありますか? もしそうなら、どうすればそれを行うことができますか?