Quelle est l'utilité des fichiers .map produits par l'éditeur de liens?
Quelle est l'utilisation des fichiers .map que l'éditeur de liens VC++ produit lorsque le paramètre/MAP ou le paramètre de projet "Générer un fichier de carte" est utilisé? Quand en ai-je besoin et comment en bénéficier?
Un bel article sur la façon d'utiliser les fichiers de carte pour trouver les plantages.
http://www.codeproject.com/KB/debug/mapfile.aspx
Faire manuellement tout cela est très inintéressant.
Je ne connais aucun outil capable de lire le fichier de carte et d'aider à trouver l'emplacement de l'accident. Si quelqu'un le sait, veuillez nous mettre à jour.
Pour les systèmes embarqués, les fichiers cartographiques sont beaucoup plus utiles. (Bien que vous n'utilisiez pas Visual C++ pour cela;)
Des choses comme savoir à quel point vous êtes à court de mémoire de programme/données et l'emplacement dans lequel réside une variable particulière sont importantes.
WinDBG utilise des fichiers .map et .pdb pour aider au débogage des plantages lors de l'analyse des vidages sur incident .hdmp et .mdmp.
Fondamentalement, ils mappent les adresses mémoire aux fonctions et variables dans le .exe (ou .dll). Très utile en général.
EDIT: Le moyen le plus utile pour déboguer "après coup" se bloque en utilisant WinDbg pour moi (plate-forme Windows). Ouvrez-le et ouvrez le vidage sur incident. Ensuite, définissez le chemin source pour pointer vers le code (si vous l'avez), le chemin du symbole pour pointer vers votre .map et .pdb et le chemin de l'image vers le .exe, et tapez "! Analyse -v" dans la ligne de commande . Vous avez maintenant une trace de pile complète avec des lignes de code et tout.
C'est encore mieux si vous avez le serveur de symboles MS dans le chemin d'accès et si le segment de mémoire pleine page a été activé ou si adplus était en cours d'exécution. Découvrez mes deux ressources WinDbg préférées:
Premier arrêt :: http://www.Microsoft.com/whdc/devtools/debugging/debugstart.mspx
Forcer le chargement des symboles :: http://www.osronline.com/ShowThread.cfm?link=182377
Site utile :: http://www.dumpanalysis.org/blog/index.php/category/windbg-tips-and-tricks/page/7/
Vous en avez rarement besoin, mais ils peuvent être utiles pour déboguer certains problèmes car ils fournissent des informations sur l'emplacement des fonctions et des données.
Par exemple:
- des informations détaillées sur tous les segments (code, données et autres).
- lier les numéros de ligne au code
Vous pouvez utiliser des fichiers de carte pour les outils de débogage.
Les cartes de l'éditeur de liens peuvent être très utiles dans les grands projets lorsque vous devez suivre les dépendances entre les unités de compilation et les bibliothèques. En règle générale, un éditeur de liens signale un symbole qui a causé des problèmes et, le plus souvent, une simple recherche de ce nom de symbole ne renvoie aucun résultat (ou renvoie des tonnes de faux positifs pour des symboles comme read).
Sans une carte de l'éditeur de liens, la seule option que vous avez est d'analyser tous les fichiers source disponibles (après le prétraitement si des macros ont été utilisées, ce qui est généralement le cas) et d'espérer que vous trouverez l'endroit approprié.
Les cartes de l'éditeur de liens ont généralement une section appelée "référence par fichier/symbole" qui vous indique quel fichier objet était requis par un autre fichier objet de votre projet, et quel symbole était exactement référencé.
Je travaillais une fois sur un projet qui devait être porté sur un système sans prise en charge locale. L'éditeur de liens signalait une "référence non définie à _localeconv_r ", ce qui aurait été difficile à rechercher en cherchant dans les sources. Heureusement, un fichier de carte de l'éditeur de liens GCC généré avec -Map=output.map a révélé toutes les fonctions problématiques avec une seule recherche.