問題タブ [gnu-assembler]

Linux で作成した最も単純なアセンブリ プログラムでさえ、FreeBSD マシンで実行するのに問題がありました。問題のあるコードは次のとおりです（これをできるだけ単純にしようとしています）：

Linux マシンは予期される結果である 60 を返しますが、FreeBSD マシンは戻りコードとして一貫して 164 を返します。これがなぜなのか誰か知っていますか？もしそうなら、何が起こっているのか説明してもらえますか？また、どちらも実際に x86 CPU を実行していることに言及する必要があります。前もって感謝します ：）

実際、私のプログラムは次のように単純です。

しかし、アセンブリの出力はかなり長いです:

私が理解していないのは、このブロックです：

変なお願いですが、出来る気がします。GCC のレジスタ アロケータがそれらを使用しないように、いくつかのプラグマまたはディレクティブをコード (C で記述) の領域に挿入したいと考えています。

このようなことができることを理解しています。これにより、この変数用にこのレジスタが確保される可能性があります

問題は、新しい命令 (ハードウェア シミュレータ用) を直接挿入していて、GCC と GAS がまだこれらを認識していないことです。新しい命令は既存の汎用レジスタを使用できますが、それらのいくつか (つまり、r12->r15) を確保したいと考えています。

現在、私はモックアップ環境で作業しており、実験を迅速に行いたいと考えています。将来的には、GAS を追加し、組み込み関数を GCC に追加しますが、今は簡単な修正を探しています。

ありがとう！

私は十分にグーグルで検索しましたが、角かっこが何()を意味するのか理解できませんでした。また、私はいくつかの構文を次のように見ていますmovl 8(%ebp), %eax

誰かが私にいくつかの良い参考文献を提案できますか？Googleの上位20件の結果から何も見つかりませんでした。

一般的に次のような構造を持つ NASM ファイルがいくつかあります。

私はそれらを次のように組み立てています：

代わりに GAS を使用してこれらのいくつかを書きたいと思います。2 つの質問:

• GAS ではどのディレクティブを使用する必要がありますか? 「.org」ディレクティブは見つかりましたが、GAS には「.bits」ディレクティブがないようです。

• プレーン バイナリ ファイルを生成するには、gcc何を渡す必要がありますか? asつまり、-f binオプションが NASM で行うことです。

次の行があるNASMファイルがいくつかあります。

このbmdev.asmファイルには、次のようなequディレクティブがあります。

を含むファイルはbmdev.asm、それらのアイテムを呼び出すことができます。つまり

これをGASに変換する方法はありますか？私が直接翻訳をしようとすると、すなわち

それは正しいものに分解されていないようです：

NASM呼び出しは、次のように分解されます。

ここでの目標は、NASMではなくGASを介してBareMetalOSのバイナリを生成することです。

動作するバイナリの完全な逆アセンブル：

動作しないバイナリの完全な逆アセンブル：

この質問の（うまくいけば）より明確なバージョンを投稿しました。これを閉じます。

私は現在のマシンで古いプロジェクトをコンパイルしようとしています。この古いプロジェクトが古い（2.x）バージョンのGCC / GASを使用していたことを知っているので、現在のバージョンでコンパイルできるようにクリーンアップする必要があります。

問題のコード：

gaspushflそれは指示ではないと文句を言います。私が読んだところによると、これは古い非推奨のGNUニーモニックですが、x86_64に相当するものがあるはずです。

pushflこのコードをx86_64ガスに変換する方法に答えるだけでなく、ニーモニックがどこでどのようにpushfq定義され、文書化されているかを誰かが説明できれば素晴らしいと思います。それがGASの作品だと確信しています...

注：これをgcc4.6.1とgas2.21でコンパイルしたい

以下は小さな NASM プログラムです。

組み立てます:

それを分解します：

GASバージョンは次のとおりです。

組み立ててリンクします。

それを分解します：

ご覧のとおり、逆アセンブルされたコードはわずかに異なります。callNASMのコード:

対ガス:

GAS バージョンを適切に実装する方法について何か提案はありますか?

FASM のプログラムは次のとおりです。

それは正しいことをします：

GCC で問題を引き起こすシナリオがあります。私が得る行動は、私が期待する行動ではありません。状況を要約すると、ハードウェア シミュレータに実装される x86-64 用のいくつかの新しい命令を提案しています。これらの命令をテストするために、既存の C ソース コードを使用し、16 進数を使用して新しい命令をハンドコーディングしています。これらの命令は既存の x86-64 レジスターと対話するため、入力/出力/クロバー リストを使用して GCC の依存関係を宣言します。

何が起こっているかというと、printf などの関数を呼び出すと、依存するレジスタが保存および復元されません。

例えば

101 は r9 に割り当てられ、インライン アセンブリ (この例では偽物) は r9 に依存しています。これはprintfがなくても正しく実行されますが、ある場合、GCCはr9を保存および復元せず、カスタム命令が呼び出されるまでに別の値がそこにあります。

おそらくGCCが変数r9への代入をこっそり変更したのではないかと思ったのですが、こうすると

アセンブリの出力を確認すると、実際に %r9 が使用されています。

gcc 4.4.5 を使用しています。何が起こっていると思いますか？GCC は常に関数呼び出しでレジスタを保存および復元すると思っていました。強制できる方法はありますか？

ありがとう！

編集：ちなみに、私はこのようなプログラムをコンパイルしています

次のプログラムを組み立てようとしています：

「gcc -o test test.s main.c」と実行すると、次のようになります。

otool -v -t テスト

jmp は、go_out ラベルでマークされた 0x100000d29 ではなく、完全に間違ったアドレス 0x200000d14 にジャンプしようとしています。

助けてください。