問題タブ [fastcall]

Windows で mingw を使用して、C およびアセンブリでコードをコンパイルしています。いくつかの関数には、fastcall 呼び出し規約 (Microsoft が定義しているように) があります。宣言で __fastcall を使用すると、mingw は Windows と同じように名前を装飾します。

アットマーク (@) は名前の前に付けられます。パラメーター リスト内のアット マークの後にバイト数 (10 進数) が名前の末尾に付けられます。

これはうまくいきます。アセンブリに次の形式のラベルがあります。

しかし、Linux (x86、32 ビット) に移植する場合、これは大きな問題であることがわかります。Gcc は突然 __fastcall (または __cdecl) を好まなくなり、ラベルの @ をまったく好まなくなりました。Linux で gcc を取得して @ を好きにするか、Windows で mingw を取得して @ を追加しないかのどちらかです。

また__attribute__(__cdecl__)、代わりに使用できます__cdeclが、どこに行くのか戸惑っています。関数名自体の前に仮定しましたが、宣言の後、セミコロンの前に置く人を見かけます。どちらでもいいですか？

X64 用に作成された ASM ファイルがあります。リーフ機能を提供します。このファイルは MASM64/ML64 でアセンブルされています。

署名付きの C 疑似コードは次のとおりです。

ASM コードの同じ部分を次に示します。

呼び出しを実行するfastcallと、使用されているように見えますが、これはドキュメントと一致しています。最初の 2 つの引数は と に表示されますがRCX、RDXこれも一貫しています。

しかし、NULLポインターを使用したテスト ケースは、予期しない結果を生成しています。使用されているテストケースは次のとおりです。

コードをステップ実行すると、 (its ) のように見えますが、(its ) のRCXように見えますが、未知の値に対して比較が行われています。即時ウィンドウから:bufferNULLRDXbsize0x40cmp buffer, 0

13f82bcd0命令ポインターのアドレス (EIP は13F50D268) のように見えます。ESPまたはとは似ていないようEBPです。

いくつかの質問を聞きたいんです...

• ML64 が変数に使用しているアドレッシング モードは何bufferですか?
• 変数の値はどこbufferから来ていますか?
• なぜ変数に使用しML64 ないのですか?ECXbuffer
• どうすればこれを修正できますか?

32 ビットに短縮された同じコードは、正常にアセンブルおよび実行されます。ただし、ML はbufferとbsizeをスタックに置き、 に対して相対的にアドレス指定しますEBP。

にも変更してみましcmp QWORD PTR buffer, 0たが、だめでした。