問題タブ [dlsym]

1)。関数のアドレスを直接出力:

2)。dlsym バージョン:

しかし

3)。その他:

strerror_r=0x8049e20を使用するにはどうすればよいdlsym()ですか?

最初に strerror_r のアドレスを出力してから、dlsym() を呼び出します。

strerror_r=0xb76544e0 は間違ったアドレスです。このアドレスで strerror_r を呼び出しても何もしません。

私の主な質問は、なぜ配列がそのような奇妙なことをするのか、そして「クリーンな」方法で次のことを行う方法があるかどうかです。

私は現在、おおよそ以下のコードのように、foo.cFortranプログラムとインターフェースするCプログラムを持っていbar.f90ます。dlopen/dlsym

foo.c：

bar.f90：

主な利回りを実行します

これは、Fortranが配列を正しく割り当て、指定された値を正しく格納していることを示していますが、dlsymを介してアクセスできなくなりました（そのデータで作業するとsegfaultが発生します）。固定サイズの配列でもこれを試しましたが、結果は同じです。

誰かがこの行動の理由を知っていますか？個人的には、双方向で動作するか、まったく動作しないことを期待していました。この「FortranはC配列を受け入れますが、その逆はありません」ということで、この方法でCから配列にアクセスする際に基本的な間違いがあったのではないかと思います。

もう1つの（そしてさらに重要な）質問は、これらの「正しい方法」のような配列アクセスをどのように行うかです。現在、「Fortran as .so」インターフェースに固執することが良い方法であるかどうかさえわかりません。この場合、混合プログラミングを試みることも可能だと思います。それにもかかわらず、配列の問題は残っています-これはISO Cバインディングを使用して何らかの方法で解決できることを読みましたが、まだその方法を理解できませんでした（Fortranではあまり作業していませんが、特に上記のバインディングでは作業していません） 、この問題についてのヘルプをいただければ幸いです。

編集：

さて、私はISO Cバインディングをもう少し読んで、ここで非常に便利なアプローチを見つけました。を使用C_LOCすると、Fortran構造体へのCポインターを取得できます。残念ながら、配列へのポインタはポインタへのポインタのようであり、C配列として扱う前に、Cコードで逆参照する必要があります。

編集：

少なくとも大部分は、ウラジミールFが指摘したように、Cバインディングを使用してプログラムを動作させることができました。CファイルとFortranファイルがリンクされたので、少なくともFortranの部分ではlibdlインターフェイスを回避できます。動的Cライブラリをロードし、そこにあるシンボルの1つへの関数ポインターを取得して、それを渡す必要があります。後で計算の一部としてその関数を呼び出すFortranへの関数ポインターとして。上記の関数はdouble*s [arrays]を期待しているので、奇妙なことに、C_LOCを使用してFortran配列を渡すことができませんでした。C_LOC(array)またC_LOC(array(1))、正しいポインターをC関数に戻すこともできませんでした。array(1)しかし、トリックをしました。悲しいことに、これはこれを行うための「最もクリーンな」方法ではありません。誰かが私にこれを使用してこれを行う方法のヒントを得た場合C_LOC機能、それは素晴らしいでしょう。それにもかかわらず、私はそれがより安全な解決策であると考えるので、ウラジミールFの答えを受け入れます。

LD_PRELOADメカニズムを使用してpthread_cond_broadcastへの呼び出しを挿入しようとしています。挿入されたpthread_cond_broadcast関数は、元のpthread_cond_broadcastを呼び出すだけです。ただし、pthread_cond_waitとpthread_cond_broadcastの両方が呼び出される非常に単純なpthreadコードの場合、glibcでセグメンテーション違反が発生するか（glibc 2.11.1の場合）、プログラムがハングします（glibc 2.15の場合）。その上で何か手がかりが起こっていますか？

介入コード（共有ライブラリとしてコンパイルされます）：

単純なpthreadプログラム：

編集：

glibc 2.11.1の場合、gdbbtは次のようになります。

編集2：

（解決済み）R ..（ありがとう！）が提案したように、問題は、私のプラットフォームではpthread_cond_broadcastがバージョン管理されたシンボルであり、dlsymが間違ったバージョンを提供することです。このブログでは、この状況について詳しく説明しています：http: //blog.fesnel.com/blog/2009/08/25/preloading-with-multiple-symbol-versions/

host.cpp には次のものがあります。

そして p1.cpp は次のとおりです。

(私は意図的にエラーチェックアウトを残しました)

ホスト実行時「ふううううう！！！」完全に異なる関数シグネチャを使用してシンボルへの void ポインターを型キャストしたにもかかわらず、正しく出力されます。

なぜこれが起こったのですか?この動作は異なるコンパイラ間で一貫していますか?

dlopenオブジェクトをロードdlsymし、共有オブジェクト関数への関数ポインタを取得するために使用しました。すべて正常に動作します。私はそれをテストしてから、共有関数を呼び出してテストしましたが、これは（今のところ）印刷するだけで、それを呼び出すメインプログラムで正常に印刷されます。ここで、この関数に 2 つの引数を渡したいと思います。int共有関数に引数をchar *渡す方法を理解できる人はいますか? Webで検索しましたが、その仕組みがわかりません。

Linuxの場合。dlsym（3）Linuxのマニュアルページによると、

シンボル（具体的には関数の場合）が実際にNULLになるのはなぜですか？コードを確認しているところ、最初にdlerrorを使用してクリーンアップし、次にdlsymを使用して、エラーをチェックするためにdlerrorを使用している部分を見つけました。ただし、呼び出す前に、結果の関数がnullであるかどうかはチェックされません。

• dlerror（）;
• a_func_name = ... dlsym（...）;
• if（dlerror（））goto end;
• a_func_name（...）; // a_func_name==NULLかどうかはチェックしません;

私は単なるレビュー担当者なので、チェックを追加するオプションはありません。そして、おそらく作者はNULLが返されることは決してないことを知っています。私の仕事はそれに挑戦することですが、これが有効なNULLを返す原因がわからないため、このコードのコンテキストでそのような条件が満たされるかどうかを確認できます。グーグルで読むべき正しいものを見つけていないので、あなたがどれが素晴らしいかを明確に説明したいのでなければ、良いドキュメントへのポインタで十分でしょう。

dlsym を介して例外を伝播できません。dlsym を使用して、cythonized python ファイルをロードします。以下に最小限の作業例を作成したので、自分で試すことができます。

Cython を使用して C ファイルにコンパイルする pyx ファイル c_fun.pyx があります。次に、dlsym を使用して、use_fun.c++ などの別のプログラムで so ファイルをロードしています。./compile.sh を使用してファイルをコンパイルできます。./test を実行すると、プログラムがセグメンテーション違反でクラッシュします。

最初は、関数の最後に「except*」を付けずに、「-fexceptions」コンパイラ フラグを付けずに試しました。ただし、それらを追加しても動作は変わりません。gdb では、問題をバックトレースすることさえできず、「新しいスレッドが見つかりません: 一般的なエラー」と表示されます。dlsym と組み合わせて例外処理をインターネットで調べましたが、ほとんど情報が見つかりませんでした。

ストーリーの残りの部分: さらに複雑にするために、実際には、この use_fun.c++ ファイルは、私がインポートした Python モジュールです。つまり、Python を使用してモジュール use_fun をロードしています。その C++ モジュールでは、_myfunction が呼び出されます。しかし、それでも、例外処理を正しく行うことができません。ただし、その場合、gdb を使用して C コードにアクセスし、PyErr_Format が正常に呼び出されたことを確認しました。ただし、C++ コードではエラーはトリガーされず、キャッチされません。

ファイル _myfunction を公開できるようにするために、pyx ファイルで「public」キーワードを指定したことに注意してください。これがないと、名前マングリングによって dlsym 関数呼び出しが失敗します。次の 2 つのリンクに関するドキュメントを探してみました。

http://docs.cython.org/src/userguide/external_C_code.html#using-cython-declarations-from-c

http://docs.cython.org/src/userguide/language_basics.html#error-return-values

編集：解決策を見つけました。他の人に役立つように、上記の元の質問をそのままにしておきます。基本的に2つの問題がありました

1) もちろん、C には例外がないので、関数に try/catch を設定するのは間違っていました! うまくいくのは、PyErr_Occurred() を使用して Python でエラーが発生したかどうかを確認することです。

2) cython はモジュールを生成するため、適切に使用する前に初期化する必要があります。これは、Py_Initialize/Py_Finalize を呼び出し、さらに init_cfun メソッドを呼び出すことを意味します。

解決策を以下に示します。

dlopen(NULL, ...)静的にコンパイルされたバイナリのシンボルを実行して取得する希望はありますか？

たとえば、次のコードを使用すると、プログラムが動的にコンパイルされ、を使用する場合にシンボルを取得できます-rdynamic。

しかし、-static私は不可解なエラーメッセージを受け取ります：

のソースは次のfoo.cとおりです。

ライブラリが同じシンボルの複数のバージョンを定義している場合、dlsym(RTLD_NEXT, "symbol")古いシンボルがデフォルトのシンボルではない場合でも、古いシンボルを返します。

たとえば、libpthreadはpthread_cond_broadcastの2つのバージョンを定義します。

• 「GLIBC_2.3.2」は、libpthreadとリンクするときに取得するデフォルトバージョンです（dlsymの関与なし）。（デフォルトの記号を表す「@@」に注意してください）
• 「GLIBC_2.2.5」は古いバージョンです

ここで、dlsym（RTLD_NEXT、 "pthread_cond_broadcast"）を使用すると、GLIBC_2.3.2バージョンではなく、常にGLIBC_2.2.5バージョンを取得します。もちろん、dlvsymを使用してデフォルトバージョンを取得することもできますが、多数のシンボルに対してそれを行う必要があり、それらの多くが異なる新旧バージョンを持っている場合、それは複雑になります。

RTLD_NEXTは、互換性を維持するために常に最新のシンボルを返す必要はないことを理解していますが、デフォルトのシンボルを返さないのはなぜですか？

誰かがこれの背後にある理論的根拠について知っていますか？

I'm facing a little problem in C++.

So, I have a game, a sort of Snake, and I want to do it with three different graphic libraries. (like libsdl.so, libndk.so and libQt.so).

I have the following classes :

DisplaySDL.hh :

DisplaySDL.cpp:

And I have my Interface "IDisplay" :

(I just put the DisplaySDL.hh and DisplaySDL.cpp as the other libs have the same design pattern / functions)

And here's the code that load the different libraries and create a IDisplay * object. :

The thing is that my function loadLibFromName() is working great, it loads the library that I tell it, BUT only when I don't have any function member in any of my graphic lib. If I remove the "boucle()" function from my code, it works great as shown below :

Otherwise, that's what I get when I try to load the lib :

Any help ? :)