Какое использование файлов .map, создаваемых компоновщиком?

Ответ 1

Хорошая статья о том, как использовать файлы карт для поиска сбоев.

http://www.codeproject.com/KB/debug/mapfile.aspx

Вручную делать все это очень неинтересно.

Мне не известны никакие инструменты, которые могут читать файл карты и помогать в поиске места сбоя. Если кто-нибудь знает, пожалуйста, уточните нас.

Ответ 2

Для встроенных систем файлы карт намного полезнее. (Хотя вы бы не использовали Visual С++ для этого;)

Важно знать, как близко вы заканчиваете работу с памятью программы/данных и какое место занимает конкретная переменная.

Ответ 3

WinDBG использует файлы .map и .pdb, чтобы помочь отлаживать сбои при анализе аварийных дампов .hdmp и .mdmp.

В основном они сопоставляют адреса памяти с функциями и переменными в .exe(или .dll). Очень полезно вообще.

EDIT: Самый полезный способ отладки "после факта" сбоев использует WinDbg для меня (платформа Windows). Откройте его и откройте аварийную свалку. Затем установите исходный путь на код (если он у вас есть), путь к символу, указывающий на ваш .map и .pdb и путь к файлу .exe, и введите "! Analysis -v" в командной строке, Теперь у вас есть полная трассировка стека с строками кода и всего.
Это даже лучше, если у вас есть сервер символов MS в пути, и если включена полная куча страницы или запущен adplus. Посмотрите эти два моих любимых ресурсов 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/

Ответ 4

Вы нуждаетесь в них редко, но они могут быть удобны в отладке некоторых проблем, поскольку они предоставляют информацию о расположении функций и данных.

Например:

• подробная информация обо всех сегментах (код, данные и прочее).
• номера строк ссылок для кода

Вы можете использовать файлы карт для инструментов отладки.

Ответ 5

Карты компоновщика могут быть очень полезны в больших проектах, когда вам нужно отслеживать зависимости между единицами компиляции и библиотеками. Как правило, компоновщик будет сообщать о символе, который вызвал проблемы, и чаще всего простой поиск этого имени символа не возвращает никаких результатов (или вернет массу ложных срабатываний для таких символов, как read).

Без карты компоновщика единственная опция, которую вы имеете, - это проанализировать все доступные исходные файлы (после прохождения предварительной обработки, если были использованы макросы, что обычно имеет место), и надеемся, что вы найдете соответствующее место.

Обычно на картах Linker есть раздел под названием "reference by file/symbol", который сообщает вам, какой объектный файл был нужен другим объектным файлом вашего проекта, и на какой символ были указаны ссылки.

Я когда-то работал над проектом, который нужно было портировать в систему без поддержки локали. _localeconv_r сообщал "неопределенные ссылки на _localeconv_r " ошибки, что было бы болью для отслеживания путем поиска через источники. К счастью, файл карты компоновщика GCC, сгенерированный с помощью -Map=output.map выявил все проблемные функции с одним поиском.