Собственно, сабж. Мы выпустили плагин для Visual Studio, позволяющий писать (IntelliSense), собирать и отлаживать embedded- и линуксовые приложения на базе GCC/GDB.
Сайт пока только на английском, русскоязычная поддержка присутствует (ru_support@visualgdb.com).
P.S. Вот тут 10 причин,почему отладка с помощью Visual Studio экономит время и силы.
Здравствуйте, bazis1, Вы писали:
B>Собственно, сабж. Мы выпустили плагин для Visual Studio, позволяющий писать (IntelliSense), собирать и отлаживать embedded- и линуксовые приложения на базе GCC/GDB.
Интересно. Спасиб. Приду на работу, посмотрю подробнее...
Здравствуйте, bazis1, Вы писали:
B>Собственно, сабж. Мы выпустили плагин для Visual Studio, позволяющий писать (IntelliSense), собирать и отлаживать embedded- и линуксовые приложения на базе GCC/GDB. B>Сайт пока только на английском, русскоязычная поддержка присутствует (ru_support@visualgdb.com).
B>P.S. Вот тут 10 причин,почему отладка с помощью Visual Studio экономит время и силы.
Круто! А как насчет freeware версии для Visual Studio Express (для использования в Open Source проектах)?
Re: Visual Studio и GDB
От:
Аноним
Дата:
10.03.12 17:14
Оценка:
B>Собственно, сабж.
а про wingdb вы слышали когда-нибудь ?
Здравствуйте, Аноним, Вы писали:
B>>Собственно, сабж. А>а про wingdb вы слышали когда-нибудь ?
собственно, идея сделать VisualGDB появилась после неудачных попыток заставить сабж работать в нашей среде
из фич, которых мы не нашли в сабже:
* авто-импорт Include-директорий в IntelliSense
* интеграция в виде NMake Project с возможностью донастроить пути
* full-custom режим, под которым можно заскрпитовать отладку чего угодно, начиная с Eclipse-based проекта под какую-нибудь узкоспециализированную плату типа DigiConnect и заканчивая драйверами под MacOS.
А, ну и конечно отдельное окно, где можно напрямую посылать GDB команды и видеть, какие команды посылает студия. что весьма незаменимо если используется нестандартная embedded OS.
P.S. Кстати, скоро будет спецверсия для отладки маковских драйверов, приближающая комфорт к отладке Windows-драйверов.
Здравствуйте, RSATom, Вы писали:
RSA>Круто! А как насчет freeware версии для Visual Studio Express (для использования в Open Source проектах)?
Это тяжко. Была такая идея, но есть ровно 2 проблемы:
1) Visual Studio Express не поддерживает сторонние плагины.
2) Если сделать совсем-совсем бесплатную версию, которой можно отлаживать OpenSource проекты, то никто не будет покупать полную версию. Типа, мы поставили бесплатную для OpenSource-проектов, а весь проприетарный код отлаживаем руками в консоли.
Я прекрасно понимаю опенсорсников, так как сам во многих проектах участвовал, но как сделать продукт для Open-Source community и при этом не растерять корпоративных клиентов, я пока не представляю. Если есть годные идеи, с интересом выслушаю.
Здравствуйте, bazis1, Вы писали:
B>Собственно, сабж. Мы выпустили плагин для Visual Studio, позволяющий писать (IntelliSense), собирать и отлаживать embedded- и линуксовые приложения на базе GCC/GDB. B>Сайт пока только на английском, русскоязычная поддержка присутствует (ru_support@visualgdb.com).
B>P.S. Вот тут 10 причин,почему отладка с помощью Visual Studio экономит время и силы.
Не в тему немного... А вот нам очень хотелось бы gdb интерфейс к cdb (который из windbg)... Но что-то никто не хочет сделать такую ерундовую вещь... )
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, bazis1, Вы писали:
B>>Собственно, сабж. Мы выпустили плагин для Visual Studio, позволяющий писать (IntelliSense), собирать и отлаживать embedded- и линуксовые приложения на базе GCC/GDB. B>>Сайт пока только на английском, русскоязычная поддержка присутствует (ru_support@visualgdb.com).
B>>P.S. Вот тут 10 причин,почему отладка с помощью Visual Studio экономит время и силы.
_>Не в тему немного... А вот нам очень хотелось бы gdb интерфейс к cdb (который из windbg)... Но что-то никто не хочет сделать такую ерундовую вещь... )
А смысл? Драйверы из-под студии можно отлаживать с помощью VisualDDK. Есть отладчик мощнее студии, требующий интерфейса GDB?
Здравствуйте, bazis1, Вы писали:
B>А смысл? Драйверы из-под студии можно отлаживать с помощью VisualDDK. Есть отладчик мощнее студии, требующий интерфейса GDB?
Чисто отладчики не знаю. А вот редакторы мощные почти все имеют интеграцию именно с gdb, а не с cdb. Разве что у QTCreator была, но нам он не нужен. В данный момент мы используем графический интерфейс самого windbg — в принципе всё хорошо, т.к. отладка это не постоянный процесс, а скорее исключение, ради которого нормально запустить отдельное приложение. Но в одной IDE всё равно было бы интереснее)
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, bazis1, Вы писали:
B>>А смысл? Драйверы из-под студии можно отлаживать с помощью VisualDDK. Есть отладчик мощнее студии, требующий интерфейса GDB?
_>Чисто отладчики не знаю. А вот редакторы мощные почти все имеют интеграцию именно с gdb, а не с cdb. Разве что у QTCreator была, но нам он не нужен. В данный момент мы используем графический интерфейс самого windbg — в принципе всё хорошо, т.к. отладка это не постоянный процесс, а скорее исключение, ради которого нормально запустить отдельное приложение. Но в одной IDE всё равно было бы интереснее)
Эээ. Дык VisualDDK именно это и делает — позволяет отлаживать драйвера из-под Visual Studio. Зачем тогда сторонняя IDE?
Здравствуйте, bazis1, Вы писали:
B>Эээ. Дык VisualDDK именно это и делает — позволяет отлаживать драйвера из-под Visual Studio. Зачем тогда сторонняя IDE?
Эээ потому что она лучше чем Visual Studio? ))) И я не про отладчик, а про другие функции. ))) Собственно говоря отладчик — это не основная деталь IDE. )))
Здравствуйте, 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.
