/ MAPパラメーターまたは「マップファイルの生成」プロジェクト設定が使用されている場合、VC++リンカーが生成する.mapファイルの使用は何ですか?いつそれらが必要になり、どのように恩恵を受けるのですか?
クラッシュを見つけるためにマップファイルを使用する方法に関する素晴らしい記事。
http://www.codeproject.com/KB/debug/mapfile.aspx
これをすべて手動で行うのは非常に面白くない。
マップファイルを読み取り、クラッシュの場所を見つけるのに役立つツールはありません。誰でも知っている場合は更新してください。
組み込みシステムの場合、マップファイルの方がはるかに便利です。 (ただし、Visual C++を使用することはありませんが;)
プログラム/データメモリがどれだけ不足しているか、特定の変数がどの場所にあるかを知ることが重要です。
WinDBGは.mapおよび.pdbファイルを使用して、.hdmpおよび.mdmpクラッシュダンプを分析するときにクラッシュをデバッグします。
基本的に、メモリアドレスを.exe(または.dll)内の関数と変数にマップします。一般的に非常に便利です。
編集:「事後」クラッシュをデバッグする最も便利な方法は、WinDbg for me(Windowsプラットフォーム)を使用することです。開いて、クラッシュダンプを開きます。次に、ソースパスがコード(ある場合)を指すように設定し、シンボルパスを.mapおよび.pdbを指すようにし、イメージパスを.exeに設定し、コマンドラインに「!analyse -v」と入力します。 。これで、コード行とすべての完全なスタックトレースができました。
パスにMSシンボルサーバーがあり、フルページヒープがオンになっているか、adplusが実行されている場合はさらに良いです。私のお気に入りの2つのWinDbgリソースをご覧ください。
最初の停止:: http://www.Microsoft.com/whdc/devtools/debugging/debugstart.mspx
シンボルの強制ロード:: http://www.osronline.com/ShowThread.cfm?link=182377
便利なサイト:: http://www.dumpanalysis.org/blog/index.php/category/windbg-tips-and-tricks/page/7/
これらはほとんど必要ありませんが、関数とデータの場所に関する情報を提供するため、いくつかの問題をデバッグするのに便利です。
例えば:
デバッグツールにマップファイルを使用できます。
リンカマップは、コンパイルユニットとライブラリ間の依存関係を追跡する必要がある大規模プロジェクトで非常に役立ちます。通常、リンカは問題の原因となったシンボルを報告しますが、多くの場合、このシンボル名を単純に検索しても結果は返されません(または、read
などのシンボルに対して大量の誤検知を返します)。
リンカマップがない場合、唯一のオプションは、使用可能なすべてのソースファイルを分析することです(マクロが使用されている場合は前処理パスの後、これは通常のケースです)。
リンカーマップには通常、「ファイル/シンボルによる参照」というセクションがあり、プロジェクトの別のオブジェクトファイルに必要なオブジェクトファイルと、正確に参照されたシンボルを示します。
かつて、ロケールのサポートなしでシステムに移植する必要があるプロジェクトに取り組んでいました。リンカは「_localeconv_r
への未定義の参照」エラーを報告していましたが、これはソースを検索することで追跡するのが面倒でした。幸いなことに、-Map=output.map
で生成されたGCCリンカーマップファイルは、1回の検索ですべての問題のある関数を明らかにしました。