3

私はアセンブリについて読んでいます。プログラミング言語について私が理解していることから、コンパイラ (アセンブラ... 他の場所で議論されている 2 つの間に微妙な違いがあることは知っています) がオブジェクト コードを生成するようです。ディレクティブのない無愛想な機械語の数々。このオブジェクト コードは、プロセッサによって解釈された後、リンカーによって実行可能ファイルになります。私は、各プロセッサが正しいアセンブリで話されなければならないことを知っています。すなわち。.386, .486, .586 私を困惑させているのは、MASM を介して DOS プログラムを実行する場合と、NASM や GAS を使用せずに Linux を介して同じプログラムを実行する場合の違いです。ソース コードがオブジェクト コードにコンパイルされている場合、この時点でクロス プラットフォームではありませんか? Linux と同じくらい簡単に、Dell から Windows をデュアル ブートできます。ここで何が欠けていますか？

また、Immunity Debugger を使用して実行を解読する必要がないように、オブジェクト コードを表示する方法を探していました。私が書いたソースコードのディレクティブマシンコードのディレクティブだけです。Linux で objdump のような結果を生成する方法はありますか?

4

1 に答える 1

10

最新の「x86」チップは、少なくとも 3 つの異なる命令セットを認識します。DOS で使用される 16 ビットの命令セットと、さまざまなフレーバーの Windows および Linux で使用される 32 ビットおよび 64 ビットの命令セットです。

チップは同じで、同じモードで実行されている場合でも、プログラムがホスト オペレーティング システムと対話してサービス (入出力など) を取得する方法はまったく異なります。

最も単純なプログラムを除くすべてのプログラムは、一般的な操作 (文字列操作、フォーマットされた入出力、数学、自明でないネットワークなど) を支援する追加のオブジェクト コードの外部ライブラリを利用する傾向があるため、最初から書かれています。しかし、利用可能なそのようなライブラリの正確なコレクション、および重要なことに、それらを要求して対話する手段は、ホスト オペレーティング システムによって異なります。おそらく、.DLL や .so が既にシステム上に存在することを期待する (動的リンク) の代わりに、アプリケーションと共にライブラリをパッケージ化することができます (静的リンク) が、基礎となる未加工のオペレーティング システム サービスを要求することの違いは、依然として対応する必要があります。 .

さらに、java や .net などの一部のスキームは、物理プロセッサ上で直接ではなく、仮想マシンまたはシミュレートされたプロセッサ上で実行されるオブジェクト コードを作成します。仮想マシン エンジンとサポート ライブラリが互換性のある形式で利用できる場合、これらはある程度移植可能です。

objdump の mingw バージョンは、Windows 上で実行され、Windows 実行可能ファイルを処理します。これは、Linux のようなセマンティクスで Windows プログラムを構築するためのツール スイートの一部です。Linux で実行され、Windows ファイルを処理するクロス バージョンもあります。逆に言えば、WINE 互換性レイヤーは Linux で多くの Windows 実行可能ファイルを実行できます。それに対して明示的にテストできます。しかし、posix インターフェースに対して C で記述したい場合 (またはアセンブリで OS 関数に多くのラッパーを使用したい場合) は、Linux とクロス バージョンまたは mingw バージョンの gnu ツールの両方でビルドされる 1 つのコードベースを持つことができるはずです。両方のオペレーティング システムのバイナリを比較的効率的に生成できます。

于 2012-05-10T12:40:40.193 に答える