私は組み込みプログラムに取り組んでいます。avr-gcc ツール チェーンを使用して、MacBook Pro から C ソースをコンパイルします。最近まで、物事はかなり順調に進んでいました。ただし、私の最新の開発イテレーションでは、何らかの断続的なバグが発生したようです。これは、ある種のスタックまたはその他のメモリ破損エラーであると思われます。
私は Valgrind を使用したことがありませんが、絶賛されているようですが、参照のほとんどは malloc/free タイプのエラーを参照しているようです。私はmalloc'ingをしません。これは小さな組み込みプログラムであり、OS はありません。Valgrind は私を助けてくれますか? クロスコンパイルされたシナリオで静的メモリの誤った管理エラーを見つけるためにそれをどのように使用するかについての指針は、本当に役に立ちます!
または、コードのメモリ管理を検証するために検討すべき別のツールまたは手法はありますか?
はい、valgrind は間違いなくあなたを助けることができます。多くのヒープベースの分析 (不正な解放、メモリ リークなど) に加えて、その memcheck ツールは、不正な読み取りと書き込み、つまりプログラムがアクセスしてはならないメモリにアクセスする状況を検出します。この分析では、静的メモリと動的メモリを区別しません。スタック フレームの外側へのアクセス、静的配列の境界を超えたアクセスなどを報告します。また、以前に初期化されていない変数へのアクセスも検出します。どちらの状況も未定義の動作であり、クラッシュにつながる可能性があります。
Frama-Cは静的分析フレームワークです (動的分析を提供する Valgrind とは対照的です)。元々、組み込みの、おそらく低レベルのコードを念頭に置いて設計されました。Frama-C の「値分析」プラグインは基本的に、組み込みコードで知りたい C の未定義の動作 (無効なポインタへのアクセスを含む) をすべて検出します。
これは静的アナライザーであるため、コード (*) を実行しないため、クロスコンパイルのコンテキストで理想的です。オプションを探します-machdep。このオプションの値には、x86_64 x86_32 ppc_32 x86_16 が含まれます。
免責事項: 私は Frama-C の「価値分析」プラグインの貢献者の 1 人です。
(*) ただし、すべての入力を提供し、精度を最大に設定すると、クロス コンパイル + 実行と同じくらい正確にソース コードを解釈できます。