私は、10,000 行以上のアセンブリ プログラムでバグを見つけ、将来的にそれを維持することに直面しています。PIC18 マイクロチップ マイクロコントローラのアセンブラ コードに関するものです。このコードは、もはや利用できない元同僚によって書かれました。彼はドキュメントを残しておらず、彼のコードにはコメントがほとんどありません。
このコードは、いくつかの直接の goto と bra 、および相対 ($+0x06 など) も使用しているため、編集することを非常に恐れています。
彼のアセンブリ ソース コードを「新しい」C コード (または C++) に逆コンパイルし、そこから作業したいと思います。私が知りたいのですが：
これが私がそれを見る方法です：
問題空間の詳細については、Boomerang プロジェクトの FAQを確認してください。
mips 以外の pics は、コンパイラにとって非常に使いにくいものです。C を使用すると、制限リソースを消費するという点で時間がかかり、コストがかかります。
goto と branch は、プロセッサがどのように機能するかであり、問題はありません。
相対ブランチを削除してラベルに置き換えることから始めます。変更前のコードと変更後のコードのバイナリを比較することで、新しいバグが追加されていないことを簡単に確認できます。相対ブランチがすべてラベルを使用すると、他の何かを壊す心配が少なくなり、コードを追加または削除できます。
逆コンパイラは機能せず、機能しません。それは、昼食に食べたフライドポテトを腸から取り出して、元のジャガイモを元に戻そうとするようなものです（もちろん、皮付きのフライドポテトでない限り、皮なしで）. 元のソースは、アセンブラーに供給される asm になる前に何度もクックおよび処理されています。オブジェクトとリンカーを使用する場合は、もう一度クック (十分にウォームアップ) されます。途中で失われた材料が多すぎて、回復できません。
静的なバイナリ変換を実行して、C 言語の何かを取得することは非常に可能ですが、フラグを使用するアーキテクチャの場合、asm、esp よりも読み取りと保守が大幅に困難です。トランスレータは、すべてのデッド コードを完全に削除することはできません。すべての加算命令は、加算自体に加えてオーバーフローを検出するためのコードになり、オーバーフローの場合はフラグを設定し、そうでない場合はクリアし、結果がゼロに等しい場合はフラグを設定し、そうでない場合は msbit が設定されている場合は n ビットを設定し、それ以外の場合はクリアします。 av ビットの場合、符号付きオーバーフローの場合は v ビットを設定し、それ以外の場合はクリアします。トランスレータがそのデッド コードを自動的に削除できない限り、asm の単純な 1 行は C コードの 10 行になります。
逆コンパイル自体はある程度可能ですが、状況に適用できるかどうかは、利用可能なソフトウェアに依存する別のことです。個人的には、手動でコードを解読し、C で大まかにコードを再構築することから始めます。もちろん、それは退屈な作業であり、おそらく多くのエラーやバグが含まれますが、コードベースを維持することになっている場合は、その作業は後でできるだけ簡単に行うことができます。おそらく、将来のメンテナーもあなたの仕事に感謝するでしょう。