問題タブ [dead-code]

重複の可能性:
大規模な C++ レガシー アプリケーションでの「デッド コード」の検索

私のプロジェクトには、それぞれに多数のグローバル関数を含む多数の C ソース ファイルがあります。これらの多くは、呼び出し元からまったく参照されなくなりました。これらの関数のうち、誰にも参照されていないものを特定する簡単な方法はありますか?

VC で生成されたマップファイルが役に立ちそうです。しかし、関数名がいつどのようにマップ ファイルにリストされているのか正確にはわかりません。

私はこのような非常に単純なJavaコードを持っています（これは単なる抜粋です）：

Eclipseでは、コメント付きのフラグメントはデッドコードとしてマークされます。なんで？final条件に要素はありません。object変数は、サイクルの最初の部分を除いて、定数nullのどこにも割り当てられません。ただし、その後は通常はオーバーライドされますが、常に発生するとは限りません。はobject、nullでも非nullでもかまいません。

私は何かが足りないのですか？

答え

さて、私は答えを見つけました、そしてそれを示すために私は私の例に1行のコードを追加しなければなりません、それはコードの抜粋を単純化しようとしたときに誤って省略しました、しかしそれは重要です。行は次のとおりです。

したがって、オブジェクトはnull以外である必要があります。そうでない場合、例外によってコードに到達できません。この行はデバッグ目的で一時的に追加されたため、私の考慮​​から外れました。

要素が使用されるときにのみ、(非常に肥大化した大規模な) フレームワークの一部を選択的にコンパイルしたいと思います。

これを行う方法についていくつかのアイデアがありましたが、どちらも適切に実装できませんでした。

1. クラスまたはメソッドと同じ名前の定義マクロを使用して、フレームワークのその部分をプリプロセッサに含める変数を切り替えます。これを実装するアイデアがありましたが、行き詰まりました。

2. すべての関数をテンプレートとして定義して、必要になるまでコンパイラが生成しないようにする方法を見つけてください。ただし、マルチファイルプロジェクトでこれを機能させる方法はわかりません。

サードパーティのコンパイラやアドオン/ツールを使用せずにこれを行う良い方法はありますか?

大きなライブラリ liblarge と、liblarge にリンクするアプリケーション app があるとします。

Liblarge は LGPL ライセンスの下にあり、アプリは独自のライセンスの下にあります。app から使用されていないすべての「デッド コード」を liblarge から削除できるようにしたいと考えています。どうにかしてこれを行うことはできますか？おそらく使用されている関数のリストをリンカーに提供しますか?

関数があるとします

これを問題なくコンパイルして実行できます。機能が必要な場合は、渡すことができ、機能-D FEATURE_Xします。

ただし、別のファイルに入れたい場合はどうでしょうかdo_something(オプションを変更するたびにそのファイルを再コンパイルする必要はありません)。それが同じファイルにあった場合、私はそれを推測します

デッドコードの削除を適切に使用して、呼び出しを削除します。これをLTOなしで別のファイルに入れると、

コードは削除されません (知る方法がありません)。では、リンク時の最適化を有効にすると、コンパイラはFEATURE_Xリンク時の値を検出し、コードが使用されているかどうかを判断し、必要に応じて削除できますか?

フラグが設定されていないMach-O オブジェクト ファイルを生成する最も簡単な方法は何ですか?SUBSECTIONS_VIA_SYMBOLSリンカ ( を使用-dead_strip) が後でテキスト セクションを切り分けて、どの部分が使用されているかを推測しようとしないようにするにはどうすればよいでしょうか?

llvm/gcc (4.2.1) へのコマンド ライン オプションを使用.subsections_via_symbolsして最初に発行されないようにするか、既存のオブジェクト ファイルからフラグを削除するコマンド ライン ツールを使用できます。

(Mach-O 仕様に基づいてそのようなツールを自分で作成することはオプションですが、可能であれば、車輪をそれほど難しく再発明したくありません)。

プラットフォーム: iOS、XCode 4.5 を使用した OSX からのクロスコンパイル。

背景:私たちは、他社がアプリに組み込む静的ライブラリを提供しています。私たちのライブラリで問題が発生すると、スタック トレースとその他の特定の重要な情報を含むクラッシュ レポートが生成されます (運が良ければ) 後で分析できます。通常、デプロイされたアプリはデバッグ情報が取り除かれているため、スタック トレースの解釈が問題になります。アプリを自分で作成する場合は、ストリッピング前の DWARF デバッグ データを保存し、それを使用して着信クラッシュ レポートのアドレスをデコードします。しかし、アプリ メーカーがリンク手順からそのようなデータを提供してくれることに頼ることはできません。

代わりに、選択した関数の実行時アドレスをクラッシュ レポートに含めるようにしています。そこから、リンカー マップ内のアドレスとクラッシュ レポート内のアドレスの間のオフセットを推測できます。.a; に詰め込む前に、ライブラリ全体を 1 つの .o に段階的にリンクしています。大きなことは 1 つしかないため、アプリが最終的にリンクされたときに、未使用の機能を削除しても節約できることはあまりありません。残念ながら、ライブラリには使用されない小さなコードがいくつかあります (メイン機能の代替 API エントリ ポイント、エラー コードを解釈するための小さなヘルパー関数など)。-dead_strip、最終的なアプリの相対オフセットがインクリメンタルリンク操作のリンカーマップと異なるというクラッシュレポートのアドレス再構築を妨げます。

すべてのアプリ開発者に、ビルド プロセスでデッド コード ストリッピングを無効にするように求めることは現実的には不可能です。そのため、.o を「デッド ストリッピング不可」としてマークし、最終的なアプリ リンクでそれを尊重することができれば、より良い方法と思われます。

i++このコードは、forループでデッドコード警告を出し続けi、何らかの理由でforをインクリメントしていません！

重複の可能性:
exe ファイルを減らす

EXE ファイルを指定して、未使用のコードをすべて削除し、アプリケーションで実際に使用されているコードを含む新しい EXE ファイルを作成するツールは何ですか? そういうものがあってしかるべきだと思います。好奇心のためだけに。しかし、未使用のコードなしで、より小さな EXE ファイルを生成するためのツールとしては、非常に優れていると思います。

PS: Delphi は、アプリケーションで使用されるすべてのオブジェクトのコードを含むスタンドアロン EXE ファイルを生成しますが、このオブジェクトのすべての要素が実際に使用されるわけではありません。これにより、大きなファイルが作成されます。Pascal の最初のバージョンは、実際に使用されるコードのみを含み、未使用のコードを挿入せず、EXE ファイルはより小さかったことを覚えています。

多くのコードを含むプロジェクトがあり、その一部はレガシーです。ワークフローの一環として、時々、製品のすべての機能がチェックされます。この事実を使用して、コードのどの部分が使用されていないかを動的にチェックする方法があるのだろうか? (難しい部分は C++ コードです。.Net と Java はより制御下にあり、レガシーが少なくなります)。

また、大量のコードや複雑なプロジェクト (つまり、100 万行程度) で動作する動的デッド コード除去ツールはありますか?

私が見つけた同様の質問はすべて、私たち全員が準備ができている静的分析について語っています。

ありがとうございました！

Eclipseは、最後のelseifとelseはデッドコードだと言い続けていますが、私にはわかりません。

私は次のように推論します。

1. bote img0 および img1 が null でない場合、if は true と評価されます
2. false と評価された場合
   • img0 が null または
   • img1 が null または
   • img0 と img1 の両方が null です。
3. 最初の elseif は、img0 が null でない場合は true と評価され、false と評価される場合は img1 が null でない可能性がある、または img0 と img1 の両方が null である可能性がある

「死」はどこにあるのですか？

前もって感謝します。