6

これは最初はばかげた質問のように聞こえますが、ご容赦ください。

ある CPU アーキテクチャのバイナリが他のアーキテクチャでは実行されないことはよく知られています。たとえば、sparc64 チップ上で x86 バイナリを実行することは (ある種の互換性レイヤーなしでは) 不可能です。命令セットが異なるため、明らかに機能しません。

しかし、バイナリが同じ CPU 用であるが、別のオペレーティング システム用である場合、コードのどの部分が実行を妨げているのか。たとえば、x86 Linux ボックスで x86 Solaris バイナリを実行するとします。ランタイム リンカーまたはプロセス スケジューラに関連するプラットフォーム固有のスタブがあると思いますか?

知りたいです。ありがとう。

4

8 に答える 8

12

いくつかの理由があります。「金属からの距離」で並べられた主なものは次のとおりです。

  1. オペレーティング システムによって、実行可能ファイルのバイナリ形式が異なる場合があります。この場合、そもそもバイナリをロードできません。
  2. プログラムは、別の方法を使用して、システム コールを配置したいことを示す場合があります (例: INT21 と INT80)。
  3. プログラムは、他の OS には存在しないシステム コール (dlopen() など) に依存している可能性があります。
  4. プログラムは、他の OS に存在しない標準ライブラリに依存している可能性があります。
  5. プログラムは、他の OS では利用できない他のライブラリに依存している可能性があります。

もちろん、予期しない環境で実行されているプログラムが見事に失敗する可能性がある方法は他にもたくさんあります。

于 2009-05-31T15:37:26.693 に答える
5

次の 4 つの問題があります。

  1. オペレーティング システムが異なれば、バイナリ実行可能ファイルのパッケージも異なります (たとえば、Linux ELF と Windows 形式)。
  2. 異なる CPU アーキテクチャ上の異なる命令セット。
  3. オペレーティング システムが異なればシステム コールも異なります (たとえば、Win32 の CreateProcess() と Linux/Unix の fork() など)。
  4. パス、正当な文字、ディレクトリ区切り記号などの違い。

システム以外のライブラリは両方に存在すると見なされますが、それ以外の場合は別の違いです。

于 2009-05-31T15:39:42.840 に答える
3

主に API です。たとえば、Win32 API は Linux では実際には利用できません。ただし、これを回避することは可能です。 Wineを参照してください。実行形式も異なる場合があります (ELF/PE) が、かなり簡単に修正できます (Wine はこれを行い、PE 実行可能ファイルを Linux で実行できるようにします)。

また、OSが非常に似ているため、SolarisとLinuxの実行可能ファイルが混在する例は、実装がかなり簡単です（実行可能形式のELF、POSIX API、Xウィンドウシステムなど）。FreeBSD はすでに Linux 実行可能ファイルを実行できます。これがあまり一般的ではない理由は、単に需要があまりないからです。*NIX プログラムよりもはるかに多くの Windows プログラムがあるため、Wine が作成されました。FreeBSD プログラムよりもはるかに多くの Linux プログラムがあるため、FreeBSD は Linux 互換レイヤーを実装しました。Solaris も最終的に同様の機能を実装する可能性があります。ただし、その逆 (Linux 上の Solaris/BSD 実行可能ファイル) は期待しないでください。需要がないからです。

于 2009-05-31T15:32:51.813 に答える
2

バイナリ形式やその他の "パッケージ化" 機能 (これも些細なことではないかもしれません) に加えて、ほぼすべてのコード フラグメントで見られる結果もあります。のようなもの

  1. PIC により、すべてのグローバル アクセスが、GOT ポインターのリロードに関するシステム固有の仮定と、追加のオフセットに関する仮定に依存する可能性があります。
  2. 多くのシステムには特定の ABI があり、レジスタに小さな構造体を渡し、アラインメントのためにレジスタをスキップし、特別な目的のためにレジスタを予約します。一部のシステムには複数あります (ARM EABI や OABI など)。
  3. スレッド ローカル ストレージ関連の問題、スレッドごとにインスタンス化される変数は、OS が指定する機能に密接に結合されます。レジスタの選択、オフセットなど
  4. 一部の OS (特に) のウィンドウでは、特定の形式の例外処理がサポートされており、言語間およびマシン間 (DCOM 経由) の例外処理が可能です。
  5. 高レベルのクロスプログラム システム (COM などですが、Mac での Objective C の相互運用性、特定の KDE-gcc バージョンの組み合わせとの互換性など) も、VMT レイアウトに特定の要件がある場合があります。
  6. 一部のリンカとフォーマットは、セクションに対して負のオフセットをサポートしていますが、サポートしていないものもあります。

これは、調べると興味深い内容のブレインダンプにすぎないことに注意してください。おそらく完全ではなく、すべてが当てはまるわけではありません。上記のポイントのいくつかは重複する可能性があります (たとえば、TLS または PIC のレジスタを予約することも ABI の変更です)。

于 2009-06-06T12:48:22.820 に答える
1

常に移植可能であるとは限らないのは、システム固有のライブラリです。たとえば、バニラ Linux で win32 ウィンドウ API を使用することはできません (もちろん、ワインなどの回避策があることは認識していますが、これは最良の例ではありません)。

于 2009-05-31T15:31:51.317 に答える
1

他の人が言ったことに加えて、実行可能ファイルの実際の形式は異なる場合があります。そのため、OS がそれを読み込もうとすると、ファイル内の適切な場所にあるコードやデータ セグメントなどに必要な値が見つかりません。

于 2009-05-31T15:39:42.870 に答える
1

システム ライブラリと API。実際の単純なコードは機能するはずです。これが、Wine のようなレイヤーが CPU エミュレーションを行わず、Windows API を再実装するだけである理由です。

于 2009-05-31T15:34:20.407 に答える
0

すでに指摘したように、非互換性は、実行可能ファイルが参照するライブラリよりも、実行可能形式自体には関係がありません。

ここで間違っているかもしれませんが、Linuxは実際にはさまざまな実行形式と互換性があると思います

于 2009-05-31T15:35:05.150 に答える