https://www.opennet.ru/openforum/vsluhforumID3/70397.html Команда разработчиков объявила (http://sourceware.org/gdb/download/ANNOUNCEMENT) о выходе новой версии отладчика GDB 7.2 (http://www.gnu.org/software/gdb/), поддерживающего отладку на уровне исходных текстов для широкого спектра языков программирования (Ada, C, C++, Objective-C,<br>Pascal и т.д.) на различных аппаратных (i386, amd64, ARM, Power, Sparc и т.д.) и программных платформах (GNU/Linux, Unix, Microsoft Windows).<br><br><br><br><br>Список изменений (http://sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/src/gdb/NEWS?content-type=text/x-cvsweb-markup&cvsroot=src):<br><br><br>- Добавлена поддержка языка D;<br>- Улучшена поддержка C++: реализован режим поиска зависимых аргументов (ADL, Argument Dependent Lookup), улучшены возможности по использованию определенных пользователем операторов и обеспечена поддержка неизменных членов статических классов;<br>- Улучшена поддержка языка Python: появился доступ к точкам останова, экспортируемым символам, таблицам символов, потокам; добавлена возможность создания G...<br><br>URL: http://sourcew https://www.opennet.ru/openforum/vsluhforumID3/70397.html#30 Tue, 07 Sep 2010 20:34:17 GMT Nemiver<br> https://www.opennet.ru/openforum/vsluhforumID3/70397.html#29 Tue, 07 Sep 2010 14:39:32 GMT &gt;&gt; Не знаю кто виноват, но у меня с GDB две основные беды - под Linux у меня регулярно систему вешает (не иксы), <br>&gt;Если вы не дебажите ядро - тогда по идее это у вас <br>&gt;с системой проблема какая-то?! Или какого хрена пользовательский процесс что-то там <br>&gt;вешает вообще? Это похоже на баг системы для начала. <br><br>Чем бросать предположения, прочитали бы сначала другие вопросы/ответы. Разумеется я дебажу не ядро, а то что пользовательские процессы при багах в ядре могут творить чудеса - дело итак ясное.<br><br>&gt;&gt; а под виндами и падает, и тупит,<br>&gt;А под виндами работать с гнутыми утилитами конечно можно но это почему-то <br>&gt;напоминает удаление гланд через зад автогеном. <br><br>А может быть вы ещё и знаете как собрать FFmpeg без GNU'шных утилит???<br><br> https://www.opennet.ru/openforum/vsluhforumID3/70397.html#28 Tue, 07 Sep 2010 14:17:24 GMT &gt; Не знаю кто виноват, но у меня с GDB две основные беды - под Linux у меня регулярно систему вешает (не иксы), <br><br>Если вы не дебажите ядро - тогда по идее это у вас с системой проблема какая-то?! Или какого хрена пользовательский процесс что-то там вешает вообще? Это похоже на баг системы для начала.<br><br>&gt; а под виндами и падает, и тупит,<br><br>А под виндами работать с гнутыми утилитами конечно можно но это почему-то напоминает удаление гланд через зад автогеном.<br> https://www.opennet.ru/openforum/vsluhforumID3/70397.html#24 Tue, 07 Sep 2010 06:54:24 GMT вполне себе. как раз, когда я писал свой курсовик с экспортированными моделями из 3DSMax, обходилось все профайлером и текстовой выдачей. была это версия 1.3 OpenGL<br> https://www.opennet.ru/openforum/vsluhforumID3/70397.html#23 Tue, 07 Sep 2010 06:28:57 GMT Порекомендуйте нормальный графический фрондэнд, pls. Раньше использовал DDD, но он уже давно не развивается.<br> https://www.opennet.ru/openforum/vsluhforumID3/70397.html#20 Mon, 06 Sep 2010 18:48:33 GMT &gt;дебажить через gui можеть быть чревато боком. ;) тем более, если речь <br>&gt;идет об отладке на уровне графики. в одних случаях я просто <br>&gt;отлавливаю входные параметры и промежуточные результаты, выдачей в текстовом виде: сначала <br>&gt;локализировав проблематичный участок. несколько сложных случаях, или когда времени очень - <br>&gt;бэктрейс. эти два метода помогают в 100% моих случаев, в том <br>&gt;числе - отлавливать баги в классах Qt. ну это так, из <br>&gt;личного опыта. он, конечно же, не может быть всегда применен у <br>&gt;других. <br><br>Когда проблемы возникают 'на стороне' или при использовании стороннего софта, тебе уже всё равно каким дебаггером пользоваться и в каком режиме его заряжать - лишь бы откопать хотя бы тоооненькую веточку, ведущую к корню проблемы, в куче непонятных тебе системных вызовов...<br><br>А если говорить о графике - то моя графика OpenGL 2.0 и GLSL и никакой GDB не поможет тебе найти причины проблем с визуализацией ;).<br><br>Вобщем каждый дебажит как может, во многих случаях лучше std::cerr ничего не найти :P. https://www.opennet.ru/openforum/vsluhforumID3/70397.html#19 Mon, 06 Sep 2010 18:30:58 GMT дебажить через gui можеть быть чревато боком. ;) тем более, если речь идет об отладке на уровне графики. в одних случаях я просто отлавливаю входные параметры и промежуточные результаты, выдачей в текстовом виде: сначала локализировав проблематичный участок. несколько сложных случаях, или когда времени очень - бэктрейс. эти два метода помогают в 100% моих случаев, в том числе - отлавливать баги в классах Qt. ну это так, из личного опыта. он, конечно же, не может быть всегда применен у других. <br> https://www.opennet.ru/openforum/vsluhforumID3/70397.html#18 Mon, 06 Sep 2010 17:51:36 GMT &gt;если дебажить, выясняя вывал программы - проще использовать команду backtrace, а не <br>&gt;брекпоинты. может поэтому никаких странностей у меня с gdb не было. <br>&gt;<br><br>Я предпочитаю графическую среду программирования и использую мультиплатформенный Code::Blocks. Интерфес привязки к дебаггеру у него к сожалению не ахти, но backtrace, локальные переменные и прочее добро (иногда приходиться просить) он показывать умеет ;).<br>Breakpoin'ы полезны когда дебажишь вывал шаг за шагом в известной окрестности, а когда падает непойми где - ставить их попросту некуда (соответственно вся надежда как раз на backtrace).<br><br> https://www.opennet.ru/openforum/vsluhforumID3/70397.html#17 Mon, 06 Sep 2010 16:42:42 GMT если дебажить, выясняя вывал программы - проще использовать команду backtrace, а не брекпоинты. может поэтому никаких странностей у меня с gdb не было.<br>