問題タブ [name-mangling]

g ++インラインアセンブリでテンプレートクラスのメンバーのアドレスを使用する必要があります（コンパイル時の定数値として）。これを表現することは可能ですか？（私はの壊れた名前が必要だと思いますT<U>::x）。

func以下のコードが示すように、ライブラリ内の C スタイルの関数 ( ) を、異なる引数を受け入れる C++ スタイルの関数でオーバーライドしようとしました。

test.cpp を共有ライブラリ libtest.so にコンパイルし、main.cpp をコンパイルして libtest.so ライブラリにリンクしました。これは、私が得るリンクステップまで、すべて機能します undefined reference to 'func(std::basic_string<char, std::char_traits<char>, std::allocator<char> >)'。

リンカーが C++ 関数を解決できない理由を説明してもらえますか? 両方の関数が実際にライブラリにあることを nm で確認しました。リンカ エラーは、Intel コンパイラと g++ コンパイラの両方で発生します。

test.h:

test.cpp:

main.cpp:

64 ビット バージョンの Windows で 64 ビット バージョンの Visual Studio 2008 を使用しています。ライブラリ (OpenCV 2.1) にリンクするプロジェクトがあります。同じコンパイラを使用して、ソースから OpenCV をコンパイルしました。私の問題は、リリース モードとデバッグ モードの両方で発生します。

[プロパティ] ペインまたはプロジェクトで、ヘッダー ファイルを含むディレクトリを C/C++ -> [追加のインクルード ディレクトリ] の下に追加しました。.lib ファイルを含むディレクトリを [追加のライブラリ ディレクトリ] に追加し、ライブラリの名前を [リンカー] -> [入力] の下の [追加の依存関係] エントリに追加しました。

コンパイルしてリンクすると、次のようなエラーが発生します: error LNK2019: unresolved external symbol _cvFloodFill referenced in function "int __cdecl Label(class cvImage &)" (?Label@@YAHAAV?$cvImage@M@@@Z)

[リンカー] -> [コマンド ライン] -> [追加のオプション] の下に、/verbose:lib というタグを追加しました。コンパイラの出力ウィンドウに、関数を含むライブラリ (cv210d.lib) が検索されていることがわかります。(OpenCV のソースを調べたところ、問題の関数がこのライブラリで定義されていることがわかりました)

1>Linking...
1>Searching libraries
1> Searching C:\Program Files\OpenCV2.1\lib\cv210d.lib:

OpenCV ソースでは、問題の関数の宣言をラップする extern "C" 宣言があります。

ライブラリ ファイルで dumpbin /all を実行したところ、次のシンボルが定義されていることがわかりました。（Windows用のgnuツールチェーンがインストールされているので、grepを使用できます）。

C:\Program Files\OpenCV2.1\lib>dumpbin /all cv210d.lib | grep cvFloodFill
732B4 __imp_cvFloodFill
732B4 cvFloodFill
1CA __imp_cvFloodFill
1CA cvFloodFill

ご覧のとおり、リンカはシンボル _cvFloodFill を探していますが、それは定義されていません。cvFloodFill と __imp_cvFloodFill のみが定義されているため、ライブラリをコンパイルするときとライブラリにリンクしようとするときの名前マングリングが異なるというおかしなことが起こっているようです。

それが私が立ち往生しているところです。この情報を正しく解釈していますか? 名前マングリングに影響を与えるために何かする必要がありますか? ある種の異なるフラグを使用してライブラリをコンパイルする必要がありますか?

私が制御できない C++ プログラムによってロードされている D DLL があります。プログラムは、私の DLL を LoadLibrary し、GetProcAddress を使用して、1 つの引数 (ポインター) を取る「extension_load」という名前の関数を見つけます。私のD DLLには次のものがあります：

この名前は、extension_load としてエクスポートする必要がありますが、extension_load@4 としてエクスポートされているため、GetProcAddress はそれを見つけることができません。名前をマングリングせずに単純な extension_load にするにはどうすればよいですか?

g ++用のC ++名前マングリングデコーダーはありますか?

同僚が std::string に整数を追加できると考えており、そのような操作をコードのあちこちで使用していることがわかりました。

この操作でコンパイラ エラーは発生しません。理由がわかりませんoperator+ (const string& lhs, int rhs);。int は暗黙のうちに char にキャストされますか? (gcc Red Hat 4.1.2 および -Wall スイッチでコンパイル)。

そして、最も重要なのは、int が std::string に追加されたすべての行をどのように見つけるのでしょうか?

呼び出し規約を次のように指定するアプリケーション (fyi: mIRC) で動作するように、dll の簡単なテスト関数をエクスポートしようとしていました。

アプリケーションからこれを呼び出すには、test_funcを使用しますが、名前マングリングのために、思ったほど単純ではないことに気付きました。

ここでの同様のトピックを通じて、extern "C"を__declspec(dllexport)と組み合わせて使用​​することは、モジュール定義 (.def) へのマングリングを削除する同等の (ある程度) 方法であることがわかりました。ただし、extern/dllexport メソッドを使用する場合、私の関数 (例として) は常に_test_func@numbers ですが、.def は、エクスポートする必要のあるアプリケーションで使用するために必要なすべてのマングリングを削除しました。

誰かがこれがなぜなのか説明してもらえますか? 私は2つの方法に興味があります。ありがとう！

プラグインを使用して、Python でIDA Pro逆アセンブラーのスクリプトを作成しています。idapythonこれを使用して、IDA の自動分析が不足しているギャップを埋めることができます。

私が困惑した領域の 1 つは、(より適切な用語が必要なため) 「きれいな名前」を使用して場所/機能に名前を付けることです。私が意味することの例を以下に示します。

idapythonIDA Pro自体では、基本的なCっぽい関数名しか入力できません。許可されていない記号 (スコープ解決演算子など) を入力すると、アンダースコアに置き換えられます。ただし、マングルされた名前 (例: ) を手で入力すると__ZN9IOService15powerChangeDoneEm、IDA Proがこれを整形してくれます。

したがって、私の質問:パススルーするマングルされた名前を生成するにはどうすればよいidapythonですか? 利用可能な名前マングリング ライブラリはありますか? Pythonで利用できますか? マングリング機能を取り除き、g++それを回避する唯一の希望はありますか?

以前、ここで、C++ 関数はアセンブリで簡単に表現できないことが示されました。Valgrind の一部である Callgrind は、それらがデマングルされているのに対し、アセンブリではデマングルされていることを示すため、私はそれらを何らかの方法で読み取ることに興味があります。

したがって、Valgrind 関数の出力をマングルするか、関数のアセンブリ名をデマングルしたいと考えています。誰もそのようなことを試したことがありますか？あるサイトを見ていて、以下の情報を見つけました。

誰もそのようなことを試したことがありますか？Cでデマングル/マングルしたい.

私のコンパイラは gcc 4.x です。

関数名で「動的に」関数ポインターを取得するCプログラムがあります（つまり、関数名を文字列として渡し、関数へのポインターを取得します）。私はすでにdlopenとdlsymを使用してLinuxでこれを行っており、dlfcnを使用した他のUnixライクでも機能すると思います。

MinGWを使用してこのプログラムをWindowsに移植しようとしたときに、問題が発生しました。「GetProcAddress（handle、symbol_name）」を使用して名前を検索しようとすると、「symbol_name」はコールバック関数の名前であり、「handle」は「GetModuleHandle（NULL）」によって返される現在の実行可能ファイルへのハンドルです。何も取得されません。 MinGWの名前マングリングは、シンボル名に「_」を追加するためです。

明らかな解決策（必要な記号の前に「_」を付ける）は、移植性にとって少し「危険」に思えます（コンパイラーがそれらのいくつかに2つのアンダースコアを追加する可能性がありますか？わかりません）。

• コンパイラが私のシンボルに名前を付けないようにするためのより良い方法はありますか？（またはそれらのサブセット、動的に検索する必要があるコールバックのみ）;

• または、GetProcAddressに、マングルされた場合でもそれらを検出させる方法はありますか？

オプション-fno-leading-underscoreも試しましたが、すべての外部シンボルのマングリングも削除され、プログラムをstdlibなどとリンクできなくなりました（また、ドキュメントの警告は少し怖いです）。

また、純粋なCを使用していることに注意してください（コードのどの部分にもC ++はありません）。また、すべてのコードは単一の「.exe」に含まれています。

TIA