2

デバッグ ライブラリと同じ C API を持つ別の「実際の」共有ライブラリを呼び出す「デバッグ」共有ライブラリ (.so または .dll ファイル) を作成しようとしています (この場合、PKCS# をエミュレートするため)。 11 API)。しかし、デバッグ ライブラリのリンク マップが実際のライブラリのリンク マップと衝突し、デバッグ ライブラリが実際のライブラリの対応する関数ではなく独自の関数を呼び出すという問題が発生しています。POSIX dlmopen コマンドを使用してこの問題の解決策を見つけましたが、GNU の libtool を使用して同じことが可能かどうかを知りたいです。

私の Solaris 10 システムでは、テスト アプリケーションがデバッグ ライブラリに静的にリンクしている場合、次のコードはアサーションに失敗します。

#include <dlfcn.h>
int MyFunctionName() {
  int (*function_ptr)();
  void *handle = dlopen("realsharedlibrary.so", RTDL_LAZY);
  *(void **)(&function_ptr) = dlsym(handle, "MyFunctionName");
  ASSERT(function_ptr != MyFunctionName); // Fails
  return (*function_ptr)();
}

この場合、実際の共有ライブラリ内の MyFunctionName ではなく、ローカルの 'MyFunctionName' (デバッグ ライブラリ内) への関数ポインタを取得します。

LM_ID_NEWLM「dlopen」の代わりに「dlmopen」コマンドを使用し、実際のライブラリをロードするときに(パラメーターを使用して) 新しいリンク マップを作成するように dlmopen に指示することで、この問題を回避できることがわかりました。

int MyFunctionName() {
  int (*function_ptr)();
  void *handle = dlmopen(LM_ID_NEWLM, "realsharedlibrary.so", RTDL_LAZY);
  *(void **)(&function_ptr) = dlsym(handle, "MyFunctionName");
  ASSERT(function_ptr != MyFunctionName); // succeeds
  return function_ptr(); // call real function
}

残念ながら、dlmopen は libtool に含まれていないようです (つまり、libtool に lt_dlmopen 関数がありません)。

libtool コマンドを使用して同じことを行うことは可能ですか?つまり、新しいライブラリをロードするときに新しいリンク マップを作成して、デバッグ ライブラリのリンク マップと衝突しないようにすることはできますか?

4

1 に答える 1

1

libtool を使用してこの問題を解決する良い方法をまだ見つけていませんが、次のフラグを指定して dlopen を使用することで、Solaris 固有の 'dlmopen' 関数を回避する方法があります。

void *handle = dlopen("realsharedlibrary.so", RTLD_NOW | RTLD_GROUP | RTLD_LOCAL)

どうやら、シンボルの衝突の問題は、RTLD_NOW代わりに を使用RTLD_LAZYして を追加することで解決されRTLD_GROUPます。が存在するのRTLD_LOCALは、POSIX で または のいずれRTLD_LOCALかを使用する必要があるRTLD_GLOBALか、動作が未定義であるためです。Solaris の場合、動作はデフォルトで になりますRTLD_LOCAL。

ただし、未解決の問題は、これらのタイプのフラグを lt_dlopen に渡すことができるかどうかです。

于 2009-12-03T18:06:06.720 に答える