2017-06-19 36 views
7

背景: Visual Studioで32ビットWindowsアプリケーションを構築するソフトウェア製品を取得しました。このアプリケーションを64ビットに移植したいと考えています。32ビットコンパイル済みバイナリを64ビットに変換する方法

このコードのミッションクリティカルなコンポーネントは、もともとサードパーティによってgFortranを使用して構築されたブラックボックスの静的ライブラリ(.aファイル)です。元の開発者は亡くなってしまい、Fortranのソースは不完全であり、このライブラリはビルドされていません(コンパイルされたライブラリには存在しない重大なバグも含まれています)。彼らはVCSを使用しませんでした。

問題: 私たちが持っている32ビットスタティックライブラリと機能的に同等なコードを持つ64ビットスタティックライブラリを作成したいと思います。

  • を64ビットに再コンパイルするためにC++ソースコードを取得するには雪だるまの逆コンパイラを使用して:私が試した何

    。生成されたコードは、gcc固有のように見える低レベルの組み込み関数を使用するため、これは不可能でした。このような組み込み関数は、64ビットで機能的に同等ではないコードにコンパイルされるため、とにかく動作しない可能性があります。おそらく、より良いデコンパイラが必要になるでしょう。

  • 明らかにx86アセンブリは有効なx86_64アセンブリですので、なぜ私は64ビットアセンブラでアセンブリを実行できないのかを簡単に見ました。 ABIは64ビットで異なっているので、呼び出し規約は一致しません。私は手作業で関数呼び出しを適切な規約に変換し、残りを同じままにしておくことができましたが、それは扱いにくい問題かもしれません。意見ですか?
+5

*「生成されたコードは、gcc固有のように見える低レベルの組み込み関数を使用するため」*など?あなたが選んだコンパイラ(MSVC?)にこれらの翻訳がありそうです。つまり、誰もがより良いデコンパイラを必要としますが、それらは正確には利用できません。イントリンシックス全体のポイントは、プラットフォームからあなたを切り離すことです。そのため、x86-64を対象としたライブラリでそれらを使用すると、x86-64コードが得られます。さらに、あなたが言ったように、x86-32はx86-64と非常によく似ているので、コードを翻訳するのは簡単です。 SOのために広すぎる。プログラマーを雇う。 –

+1

@CodyGray私が見たものは、__return_address()と__zero_stack_offset()でした。独自の関数引数を使用して生成されたコードではなく、アセンブリコードを手動で複製して、スタックからそれらを読み取るようにしました。これは、ABIが異なるため、64ビットでは飛ばないでしょう。 __return_address()には、MSVCに相当する_ReturnAddress()があるかもしれませんが、__ zero_stack_offset()に相当するものは見つかりません。彼らは非常によく文書化されていません。あなたのご意見ありがとうございます。 – Veggie

+0

"32ビットコンパイル済みバイナリを64ビットに変換する方法" - ソースコードを64ビットに再コンパイルする。 –

答えて

7

32ビットのバイナリライブラリをそのままにして32ビットのホストプロセスにロードし、IPC(共有メモリ、名前付きパイプ、ローカルループバックネットワーク接続など)を使用してデータを転送することができます64ビットプロセスとの間で通信を行います。

このアプローチのもう1つの利点は、Fortranコードがクラッシュした場合、メインアプリケーションではなく子ホストプロセスのみが停止し、プログラムが即座に起動できることです。シングルスレッドのFortranプログラムの場合は、マルチコアの並列処理のためにいくつかのインスタンスを起動することができます。

+0

私はあなたがこれを提案するかもしれないと恐れていた... – Veggie

+2

それはハック(最高)です。楽しさを楽しみながら楽しみましょう。 –

+1

@JesperJuhl:それはハックではありません。それは本質的に、どのように(そしてなぜ)COMの代理プロセスが機能するかです。サロゲートプロセスの起動は解決された問題です。 IPCは解決された問題です。 – IInspectable

関連する問題