Представлен релиз отладчика GDB 16.1 (первый выпуск серии 16.x, ветка 16.0 использовалась для разработки). GDB поддерживает отладку на уровне исходных текстов для широкого спектра языков программирования (Ada, C, C++, D, Fortran, Go, Objective-C, Modula-2, Pascal, Rust и т.д.) на различных аппаратных (i386, amd64, ARM, Power, Sparc, RISC-V, LoongArch и т.д.) и программных платформах (GNU/Linux, *BSD, Unix, Windows, macOS)...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62582
одно из основополагающих опенсорс творений, как линукс, куему, иксы и файрфоксвсем присесть и три раза ку
Дебажу принтами зачем нужен сабж ума не приложу. Есть подробное зачем оно надо?
Ношу воду коромыслом с реки, зачем мне водопровод, ума не приложу.
А так деблохатор - это как раз таки воду коромыслом. Водопровод - это языки, которым оно не нужно как класс.
> А так деблохатор - это как раз таки воду коромыслом. Водопровод - это языки,
> которым оно не нужно как класс.А что за языки такие волшебные, что на них программы - без багов?! Я б взял парочку.
Кто же его не знает? Швятой Rust.
> Кто же его не знает? Швятой Rust.Не, вот на минутку. На нем не то что просто баги, на нем даже CVE бывают. При том даже прямо в его стдлибе.
И вот что хрустики делают если например сложное многопоточное месиво через неделю работы ловит из незабвенный panic? Или как они на ходу состояние программы смотрят, если она начинает вытворять что-то не то?
> как они на ходу состояние программы смотрятЗвучит как "на ходу быстренько остановить ракету и перепроверить деталь". Лечится юнит-тестированием, дисциплиной и прочими практиками. Но сишники привыкли дебажить уже пост-фактум в связи с тем, что компилятор не дает ценных компайл-тайм проверок.
>дисциплиной и прочими практикамиАга, значит, тоже, что и на других языках приходится делать.
Кто о чем, а веб-камаки о своих юнит тестах. Как ты напишешь юнит тест для драйвера, к-й размазан в ядре по разным подсистемам и дергается асинхронно прерываниями?
Если tokio то берут tokio-console и смотрят что там... А что?
Вообще есть один такой (дебаггер ему пока не нужен в практическом смысле слова, да его и нет 🤷♀️) - это язык Nu.И это единственный из 30 языков программирования, которому "не нужен" дебагер. И скажу честно - я в шоке.
Ты просто берёшь кусок кода и вставляешь его в оболочку NuShell - и видишь результат. Настолько атомарны конструкции языка.
Предыдущие попытки создать структурированные пайплайны тебя ничему не научили?
> Вообще есть один такой (дебаггер ему пока не нужен в практическом смысле
> слова, да его и нет 🤷♀️) - это язык Nu.А, ну если дебагера нет - он, конечно "не нужен".
> И это единственный из 30 языков программирования, которому "не нужен" дебагер. И
> скажу честно - я в шоке.
> Ты просто берёшь кусок кода и вставляешь его в оболочку NuShell -
> и видишь результат. Настолько атомарны конструкции языка.Ага, а большие, сложне программы, с нетривиальными взаимодействиями между компонентами - как? Или они просто это не практикуют - и тогда и проблемы нет? В простых вещах мне и на сишке дебагер - нахрен не упал.
Теперь возьмем жирный плюсатый проект с многопоточностью, бинарем 10 мегз и проч, и когда он через неделю упадет по фиг знает какой причине - призадумаемся что иногда и дебагер не такая уж плохая штука.
Вот прямо сейчас у меня есть кордамп с багом который я видел 1 раз за всю мою жизнь. И, конечно, я понятия не имею - как такое вообще сделать можно было. Но я более-менее вижу состояние программы на момент отвала - целиком - и понимаю в каком именно месте она споткнулась. Это дает шанс этот баг - зарулить.
> Ношу воду коромыслом с реки, зачем мне водопровод, ума не приложу.Раз уж взялись метафорами говорить ... У нас в деревне зимой проще воду в баню по субботам ведром принести. Т.к. в -30 водопровод однозначно порвет, а шланг потом невозможно обратно свернуть, не сломав. Это я к тому, что ненужно скоропалительно отвергать что бы то ни было.
А я и не отвергаю. Но вот сверху водопровод однозначон отвергают.
P.S. Впрочем, жить в деревне, да в –30° в баню бегать… такое себе.
> Дебажу принтами зачем нужен сабж ума не приложу. Есть подробное зачем оно надо?Если у тебя раз в неделю грохается здоровая многопоточная программа... то вот это может быть несколько несподручно.
Т.е. одно дело если ты получил неведомый трейс выполнения который фиг знает как воспроизвести - не говоря о хзкаком внутреннем состоянии, и другое - если вот тебе core dump и изучай себе наздоровье. И так уже бывает гораздо понятнее в чем дело. Хотя тоже без гарантий.
>> Дебажу принтами зачем нужен сабж ума не приложу. Есть подробное зачем оно надо?
> Если у тебя раз в неделю грохается здоровая многопоточная программа...... то и дебажить ее тоже такое себе удовольствие.
>>> Дебажу принтами зачем нужен сабж ума не приложу. Есть подробное зачем оно надо?
>> Если у тебя раз в неделю грохается здоровая многопоточная программа...
> ... то и дебажить ее тоже такое себе удовольствие.См выше про кордамп который я 1 раз в жизни видел. По другому такое особо и не получится.
Как-то в голову не пришло, что отладчиком можно дампы отлаживать.Со своей стороны про отладку больших систем могу сказать, что после того как современные девопсы стали всё деплоить контейнерами, отобрав возможность заходить на прод и производить какие-то действия (типа подправил код, добавил принтов, перезапустил, увидел результат), приходится в систему вставлять тонны логов и логировать всё подряд. По сути при возникновении проблемы оказывается, что "принты" уже есть и результат уже лежит в графане.
ты забыл добавить префиксом await к своему посту
>>Дебажу принтамиОдно другому не мешает, дополняет, и более того, где то уместней логи, а где то без отладчика ад.
Я когда пишу под DOS, там тоже нет поддержки нормальный дебаггеров. Только TD32, который не поддерживается HX, и WD. Оба не умеют в современные форматы отладочной информации. Т.е. средства разработки тоже нужно юзать древние. Дебагать принтами конечно классно, но все равно не удобно. Другие классные лудитские медоды дебагинга - юзать волшебный макрос #define Breakpoint asm volatile inline ("int 3":::). Метод исключения - комментить куски кода, пока не найдешь тот, который вызывает ошибку. Какие еще извращения вы знаете?
Это на чём вы пишете под DOS, что отладочная информация у вас в современном формате, а отладчика нет?
Вроде Free Pascal умеет для Dos
Да не только он умеет, вопрос в другом — что сейчас умеет собирать под DOS, но не имеет нормального отладчика?
В Open Watcom есть свой отладчик , который понимает dwarf, а Free pascal , bruce's c и Djgpp и nasm не делают свои отладчики
> Free pascalПрямо нет отладчика? Что-то не верится.
> Djgpp
Вроде ж всегда там GDB был.
> Дебагать принтами конечно классно, но все равно не удобно.В досе конечно неудобно. Нужен PAGER с возможностью скролла и поиска. И конечно же редирекция вывода в пайп. В запущенных случаях можно в текстовый редактор засунуть, но досовый текстовый редактор не вытащит больше 64Kb текста.
А, ну и сверху, если мы говорим о C, я б написал препроцессор к C, который бы добавлял няшные конструкции для отладочной печати. Чтоб без printf("%d") и тп. Нужно что-нибудь попроще, типа dbgprint("my_struc is {my_struc} now"). Плюс нужен аналог лисповой функции print, которая выводит значение ей переданное и возвращает это значение, то есть имея что-нибудь типа:
int result = foo() + bar();
можно было бы преобразоваь это в:
int result = dbg(foo()) + dbg(bar());
и узнат что там foo с bar возвращают.
Но лучше это делать не функцией, а препроцессором, чтобы тот выводил бы не просто значение, а что-то такое:
my_source.c:42: foo() == 3.14
my_source.c:42: bar() == "Hello world"> волшебный макрос #define Breakpoint asm volatile inline ("int 3":::).
Чем это отличается от printf(/* all locals */)? Если ты знаешь все локальные переменные, то ты вполне можешь рассуждать о том, что делает код без помощи отладчика. Бывают ситуации, когда это не так, но они все делятся на два класса: 1. смотрящему в код следует сменить профессию; 2. тому кто написал код следует сменить профессию, причём принудительно и с применением избыточной жестокости.
Последнее время так же делаю. Отлаживаю проект весьма небольшими фрагментами. И тестовая печать, выданная в файл, может быть удобнее для анализа.
Так это совершенно разные подходы в отладке - о чём там спор выше вообще не понятно, т.к. инъекция функций печати это банально примитивное встраивание в поток отладочных конструкций, но сложное состояние таким образом отловить сложно, поэтому и берётся отладчик, который и сразу покажет где произошёл сегфолт и более сложные инъекции и контроль позволяет осуществить, причём как с печатью, так и целиком показывая состояние локальных переменных. Другой вопрос, что не всегда чистый gdb удобен из коробки, ввиду чего удобно брать его обёртки, вроде `гитхаб/nakst/gf` или подобных.
Удачи дебажить принтами типичную легасятину десятилетнюю на 600К+ строк кода, где библы вперемешку с фреймворком и все на коллбэках, при этом их код может совершенно неочевидным образом обрабатывать как выхлоп твоей процедуры, так и нечто неочевидное передавать на вход (а документировано это может быть крайне криво). Так что тут только отладчик и по стеку вызовов гулять, изучать всю цепочку.
ПО установлено у заказчика. Отладка отключена или по минимуму, чтобы не ломать производительность. Процесс падает, но редко. Повторить у себя за конечное время - не получается.Всё что есть - дамп памяти.
Ищи без отладчика, ага.
Вот интересно... Как там нынче lldb по сравнению с gdb? Кто-нить юзает?
в VSCode и Neovim для Rust юзают lldb
В прошлом году немного поработал с lldb - не понравился, gdb лучше. Да и глюков в нём больше.
> Прекращена поддержка QNX NeutrinoИ как теперь жить?
Если речь об отладке математики, то можно это делать в поддерживаемой отладчиком системе - предполагается, что работать она должна одинаково, а в неподдерживаемой делать сборку. Ну к примеру, я делаю отладку расчетных алгоритмов в Ubuntu, а для Haiku делаю сборку, и всё в ней работает.
О, нашёлся уникальный человек, который математические расчёты делает непременно на Haiku.
GDB то может быть и хорош сам по себе. Другое дело его поддержка в средах разработки. Я никогда не работал с голым GDB. Но подозреваю, что это что то уровня работы с debug.com под DOS. Конечно можно, но не удобно. А в средах его реализация крайне кривейшая.
Я работаю, вроде норм. Переключаюсь между окном с терминалом и кодом, когда расставляю брейкпоинты, а потом уже только в терминале.
Неудобно, но в Gdb можно исходный текст просмотреть. Можно прямо во время исполнения изменить любой участок памяти. А многопоточные программы иногда только в нём получается отладить, когда точку останова на модификацию области памяти делать.
Просто нужно использовать те среды разработки, где поддержка хорошая. Например, slickedit.
Принтфы, языки, не требующие дебаггера, «писать нужно без ошибок»… а вы не пробовали не свой код отлаживать, а чужой? да не в исходниках, а в виде готовых бинарников?
Да чаще всего вопросы типа "А зачем мне ООП? У меня и так все работает" возникают у товарищей, которые ничего кроме школьных задачек и не решали. Дело в масштабируемости. Чем сложнее проект, тем круче нужны инструменты для его разработки. Благо у меня например опыта много в разработке почти без отладчика. Но корячится каждый раз с мелкими ошибками - это тоже не подарок. Однажды может не повезти и ты словишь сложную ошибку, которую трудно будет найти. Я тут недавно курьез словил. Дебагал ошибку три дня. Все было 100% ок, но не работало. Оказалось это баг в DOSBox. И я его нашел)))
И как ядро Linux без ООП живёт)
Всё тяжелее.
Там своя кустарная реализация ООП на C.
>не свой код отлаживать, а чужойА зачем? Это же что-то вроде наказания
Во-первых, есть такое понятие «надо».
Во-вторых, есть такое понятие «реверс-инженеринг». И это куда интереснее, чем принтфы в своём коде расставлять, чтобы очередной унылый выход за границы массива искать.
"Во-вторых" -- это не про gdb от слова вообще. gdb крайне неудобен для отладки бинарей без отладочной информации. И в целом обратная разработка -- это не разработка, там очень много чего по другому. Некоторые скиллы разработки оказываются полезными для обратной разработки, но большинство бесполезно. Некоторые инструменты для разработки, оказываются полезными для обратной разработки, но всё же основные инструменты обратной разработки уникальны для неё. Не надо путать тёплое с мягким.А "во-первых" это твои проблемы. Ты всегда можешь сменить место работы так, чтобы не было "надо". То есть, выходит что не надо, но ты сознательно на это идёшь.
> а чужой? да не в исходниках, а в виде готовых бинарников?Это самая большая проблема - отлаживать чужой код. На кривой и убогий Qt у меня было убито 80% времени, потраченного на проект в целом. Впрочем, полгода назад нашел лучшее решение, забыв о нем, как о кошмарном сне.
Что за решение, если не секрет?
> Что за решение, если не секрет?Электрон, разумеется!
Все просто работает.
Мы же на OPEN net. У нас код открытый.