Здравствуйте, chygyrynsky, Вы писали:

C>Hallo,
C>мне приходится анализировать core dumps (x86, QNX). Как это можно сделать с VisualGDB
Проще всего для начала — с помощью custom GDB session.
Основная идея такая: начинаем отладку как-бы в консоли. Загружаем все символы командами, все как обычно для GDB. Как только все загружено и call stack отображается правильно, нажимаем Start Debugging. После чего все то, что мы только что видели в консоли отображается в Visual Studio.

Команды для загрузки символов и т.п. можно потом автоматизировать и выполнять одним щелчком.

C>и какие преимущества имеет VisualGDB.
На мой взгляд, при отладке дампов есть 2 главные задачи:
1) Пройти по стеку, посмотреть значения переменных, понять контекст, в котором произошел сбой
2) (если код оптимизирован) открыть дизассемблер, чтобы понять, что же именно вызвало exception

VisualGDB упрощает обе задачи:
1) Очень удобно ходить по стеку двойным щелчком, сразу видеть исходный файл в Visual Studio (с работающим Go To Definition, позволяющим быстро понять, что означает "тот макрос или функция"). Видеть значения переменных (с авто-раскрытием структур), просто наводя мышь на них в исходном коде.
2) Студийный дизассемблер экономит кучу времени, показывая машинный код аннотированный фрагментами исходника. GDB по умолчанию не всегда справляется (в случае если, например, строчка 7 физически находится в памяти раньше строчки 6, что часто бывает с циклами). Мы сделали специальный алгоритм, исправляющий эту проблему.

Пошаговая инструкция:
1) Создаем solution в студии (можно пустой, можно с исходными файлами от дампа, чтобы работал Go To Definition).
2) Debug->Start Custom GDB Session
3) Указываем путь к GDB (в аргументах указываем --interpreter mi <program> <core file>)
4) Нажимаем start
5) Получаем консольное окно с GDB, где можно загрузить симмолы, установить пути и т.п.
6) Как только все символы загружены и GDB показывает нормальный стек, нажимаем Start Debugging
7) Исследуем стек уже средствами Visual Studio.