The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск отладчика GDB 16

18.01.2025 21:30

Представлен релиз отладчика 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).

Наиболее заметные улучшения:

  • Для Linux-окружений на системах с архитектурой LoongArch реализована поддержка записи и повторного выполнения (record/replay).
  • Для теггированных указателей, часть битов в которых используется для хранения дополнительных данных, реализована поддержка точек останова, срабатывающих при изменении данных (watchpoint).
  • На системах с архитектурой AArch64 реализована поддержка отладки механизма защиты MTE (Memory Tagging Extension). MTE даёт возможность привязать теги к областям в памяти и организовать проверку корректности использования указателей для блокирования эксплуатации уязвимостей, вызванных некорректной работой с памятью.
  • Добавлен bash-скрипт gstack, использующий GDB для вывода трассировок стека работающих процессов.
  • Для точек остановка в состоянии ожидания (pending) ключевые слова 'thread' и 'task' теперь разбираются во время создания точки останова, а не после выхода из состояния ожидания.
  • Обеспечена подстановка точек останова, привязанных к потокам, только в ту область программы, в которой выполняется необходимый поток.
  • Расширены возможности трассировки на процессорах Intel: при пошаговой отладке, а также в командах "record instruction-history" и "record function-call-history" реализован вывод асинхронных событий и данных, сохраняемых при использовании инструкции ptwrite.
  • В Python API добавлены: модуль gdb.missing_objfile, событие gdb.tui_enabled, атрибут gdb.Symbol.is_artificial и функция gdb.record.clear.
  • Расширены возможности протокола DAP (Debugger Adapter Protocol), связанные с обработкой запросов "scopes", "launch" и "attach".
  • В протокол удалённой отладки добавлена поддержка пакетов "vFile:stat" и "x addr,length".
  • Прекращена поддержка QNX Neutrino, Nios II и Intel MPX.


  1. Главная ссылка к новости (https://www.mail-archive.com/i...)
  2. OpenNews: Выпуск отладчика GDB 15
  3. OpenNews: Проект OpenAI открыл Transformer Debugger, отладчик для моделей машинного обучения
  4. OpenNews: Выпуск системы динамической отладки SystemTap 5.0
  5. OpenNews: Проект Debian запустил сервис для динамического получения отладочной информации
  6. OpenNews: Для Linux представлена система динамической отладки BPFtrace (DTrace 2.0)
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/62582-gdb
Ключевые слова: gdb, debug
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (54) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 21:47, 18/01/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +11 +/
    одно из основополагающих опенсорс творений, как линукс, куему, иксы и файрфокс

    всем присесть и три раза ку

     
     
  • 2.2, Аноним (2), 21:50, 18/01/2025 [^] [^^] [^^^] [ответить]  
  • –11 +/
    Дебажу принтами зачем нужен сабж ума не приложу. Есть подробное зачем оно надо?
     
     
  • 3.5, Аноним (5), 22:08, 18/01/2025 [^] [^^] [^^^] [ответить]  
  • +21 +/
    Ношу воду коромыслом с реки, зачем мне водопровод, ума не приложу.
     
     
  • 4.8, Аноним (8), 22:35, 18/01/2025 [^] [^^] [^^^] [ответить]  
  • –10 +/
    А так деблохатор - это как раз таки воду коромыслом. Водопровод - это языки, которым оно не нужно как класс.
     
     
  • 5.10, Аноним (-), 22:53, 18/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А так деблохатор - это как раз таки воду коромыслом. Водопровод - это языки,
    > которым оно не нужно как класс.

    А что за языки такие волшебные, что на них программы - без багов?! Я б взял парочку.

     
     
  • 6.12, Аноним (12), 00:01, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Кто же его не знает? Швятой Rust.
     
     
  • 7.22, Аноним (22), 11:32, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Кто же его не знает? Швятой Rust.

    Не, вот на минутку. На нем не то что просто баги, на нем даже CVE бывают. При том даже прямо в его стдлибе.

    И вот что хрустики делают если например сложное многопоточное месиво через неделю работы ловит из незабвенный panic? Или как они на ходу состояние программы смотрят, если она начинает вытворять что-то не то?

     
     
  • 8.49, Аноним (49), 02:28, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Звучит как на ходу быстренько остановить ракету и перепроверить деталь Лечитс... текст свёрнут, показать
     
     
  • 9.55, Аноним (55), 14:00, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, значит, тоже, что и на других языках приходится делать ... текст свёрнут, показать
     
  • 8.52, Аноним (52), 11:01, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Если tokio то берут tokio-console и смотрят что там А что ... текст свёрнут, показать
     
  • 6.14, Витюшка (?), 01:12, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще есть один такой (дебаггер ему пока не нужен в практическом смысле слова, да его и нет 🤷‍♀️) - это язык Nu.

    И это единственный из 30 языков программирования, которому "не нужен" дебагер. И скажу честно - я в шоке.

    Ты просто берёшь кусок кода и вставляешь его в оболочку NuShell - и видишь результат. Настолько атомарны конструкции языка.

     
     
  • 7.17, Аноним (17), 03:45, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Предыдущие попытки создать структурированные пайплайны тебя ничему не научили?
     
  • 7.23, Аноним (-), 11:47, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А, ну если дебагера нет - он, конечно не нужен Ага, а большие, сложне програм... большой текст свёрнут, показать
     
  • 4.32, Аноним (32), 15:54, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Ношу воду коромыслом с реки, зачем мне водопровод, ума не приложу.

    Раз уж взялись метафорами говорить ... У нас в деревне зимой проще воду в баню по субботам ведром принести. Т.к. в -30 водопровод однозначно порвет, а шланг потом невозможно обратно свернуть, не сломав. Это я к тому, что ненужно скоропалительно отвергать что бы то ни было.

     
     
  • 5.39, Аноним (39), 16:56, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    А я и не отвергаю. Но вот сверху водопровод однозначон отвергают.
     
     
  • 6.40, Аноним (39), 16:58, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    P.S. Впрочем, жить в деревне, да в –30° в баню бегать… такое себе.
     
  • 3.9, Аноним (-), 22:52, 18/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Дебажу принтами зачем нужен сабж ума не приложу. Есть подробное зачем оно надо?

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

    Т.е. одно дело если ты получил неведомый трейс выполнения который фиг знает как воспроизвести - не говоря о хзкаком внутреннем состоянии, и другое - если вот тебе core dump и изучай себе наздоровье. И так уже бывает гораздо понятнее в чем дело. Хотя тоже без гарантий.

     
     
  • 4.16, Аноним (-), 01:29, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Дебажу принтами зачем нужен сабж ума не приложу. Есть подробное зачем оно надо?
    > Если у тебя раз в неделю грохается здоровая многопоточная программа...

    ... то и дебажить ее тоже такое себе удовольствие.

     
     
  • 5.28, Аноним (-), 13:20, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Дебажу принтами зачем нужен сабж ума не приложу. Есть подробное зачем оно надо?
    >> Если у тебя раз в неделю грохается здоровая многопоточная программа...
    > ... то и дебажить ее тоже такое себе удовольствие.

    См выше про кордамп который я 1 раз в жизни видел. По другому такое особо и не получится.

     
  • 4.20, Аноним другой (?), 09:29, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как-то в голову не пришло, что отладчиком можно дампы отлаживать.

    Со своей стороны про отладку больших систем могу сказать, что после того как современные девопсы стали всё деплоить контейнерами, отобрав возможность заходить на прод и производить какие-то действия (типа подправил код, добавил принтов, перезапустил, увидел результат), приходится в систему вставлять тонны логов и логировать всё подряд. По сути при возникновении проблемы оказывается, что "принты" уже есть и результат уже лежит в графане.

     
  • 3.11, Аноним (11), 22:56, 18/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    ты забыл добавить префиксом await к своему посту
     
  • 3.15, _kp (ok), 01:21, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >>Дебажу принтами

    Одно другому не мешает, дополняет, и более того, где то уместней логи, а где то без отладчика ад.

     
  • 3.26, Аноним (26), 13:01, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Я когда пишу под DOS, там тоже нет поддержки нормальный дебаггеров. Только TD32, который не поддерживается HX, и WD. Оба не умеют в современные форматы отладочной информации. Т.е. средства разработки тоже нужно юзать древние. Дебагать принтами конечно классно, но все равно не удобно. Другие классные лудитские медоды дебагинга - юзать волшебный макрос #define Breakpoint asm volatile inline ("int 3":::). Метод исключения - комментить куски кода, пока не найдешь тот, который вызывает ошибку. Какие еще извращения вы знаете?
     
     
  • 4.31, Аноним (5), 14:55, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это на чём вы пишете под DOS, что отладочная информация у вас в современном формате, а отладчика нет?
     
     
  • 5.37, Аноним (37), 16:33, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Вроде Free Pascal умеет для Dos
     
     
  • 6.42, Аноним (39), 18:32, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Да не только он умеет, вопрос в другом — что сейчас умеет собирать под DOS, но не имеет нормального отладчика?
     
     
  • 7.47, Аноним (37), 21:02, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В Open Watcom есть свой отладчик , который понимает dwarf, а Free pascal , bruce's c и Djgpp и nasm не делают свои отладчики
     
     
  • 8.48, Аноним (5), 21:08, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Прямо нет отладчика Что-то не верится Вроде ж всегда там GDB был ... текст свёрнут, показать
     
  • 4.41, Аноним (-), 16:59, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В досе конечно неудобно Нужен PAGER с возможностью скролла и поиска И конечно ... большой текст свёрнут, показать
     
  • 3.33, Аноним (32), 15:56, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Последнее время так же делаю. Отлаживаю проект весьма небольшими фрагментами. И тестовая печать, выданная в файл, может быть удобнее для анализа.
     
     
  • 4.51, Андрей (??), 07:59, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Так это совершенно разные подходы в отладке - о чём там спор выше вообще не понятно, т.к. инъекция функций печати это банально примитивное встраивание в поток отладочных конструкций, но сложное состояние таким образом отловить сложно, поэтому и берётся отладчик, который и сразу покажет где произошёл сегфолт и более сложные инъекции и контроль позволяет осуществить, причём как с печатью, так и целиком показывая состояние локальных переменных. Другой вопрос, что не всегда чистый gdb удобен из коробки, ввиду чего удобно брать его обёртки, вроде 'гитхаб/nakst/gf' или подобных.
     
  • 3.44, Аноним (44), 19:00, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Удачи дебажить принтами типичную легасятину десятилетнюю на 600К+ строк кода, где библы вперемешку с фреймворком и все на коллбэках, при этом их код может совершенно неочевидным образом обрабатывать как выхлоп твоей процедуры, так и нечто неочевидное передавать на вход (а документировано это может быть крайне криво). Так что тут только отладчик и по стеку вызовов гулять, изучать всю цепочку.
     
  • 3.60, Александр (??), 18:32, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    ПО установлено у заказчика. Отладка отключена или по минимуму, чтобы не ломать производительность. Процесс падает, но редко. Повторить у себя за конечное время - не получается.

    Всё что есть - дамп памяти.

    Ищи без отладчика, ага.

     

  • 1.18, Аноним (18), 04:54, 19/01/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот интересно... Как там нынче lldb по сравнению с gdb? Кто-нить юзает?
     
     
  • 2.21, Аноним (21), 09:56, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • –2 +/
    в VSCode и Neovim для Rust юзают lldb
     
  • 2.34, Аноним (37), 16:23, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В прошлом году немного поработал с lldb - не понравился, gdb лучше. Да и глюков в нём больше.
     

  • 1.19, Аноним (19), 09:29, 19/01/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >     Прекращена поддержка QNX Neutrino

    И как теперь жить?

     
     
  • 2.43, Аноним (32), 18:58, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Если речь об отладке математики, то можно это делать в поддерживаемой отладчиком системе - предполагается, что работать она должна одинаково, а в неподдерживаемой делать сборку. Ну к примеру, я делаю отладку расчетных алгоритмов в Ubuntu, а для Haiku делаю сборку, и всё в ней работает.
     
     
  • 3.56, Аноним (55), 14:06, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    О, нашёлся уникальный человек, который математические расчёты делает непременно на Haiku.
     

  • 1.25, Аноним (26), 12:56, 19/01/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    GDB то может быть и хорош сам по себе. Другое дело его поддержка в средах разработки. Я никогда не работал с голым GDB. Но подозреваю, что это что то уровня работы с debug.com под DOS. Конечно можно, но не удобно. А в средах его реализация крайне кривейшая.
     
     
  • 2.30, Аноним (30), 14:27, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я работаю, вроде норм. Переключаюсь между окном с терминалом и кодом, когда расставляю брейкпоинты, а потом уже только в терминале.
     
  • 2.36, Аноним (37), 16:31, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Неудобно, но в Gdb можно исходный текст просмотреть. Можно прямо во время исполнения изменить любой участок памяти. А многопоточные программы иногда только в нём получается отладить, когда точку останова на модификацию области памяти делать.
     

  • 1.27, Аноним (5), 13:07, 19/01/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Принтфы, языки, не требующие дебаггера, «писать нужно без ошибок»… а вы не пробовали не свой код отлаживать, а чужой? да не в исходниках, а в виде готовых бинарников?
     
     
  • 2.29, Аноним (26), 13:33, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Да чаще всего вопросы типа "А зачем мне ООП? У меня и так все работает" возникают у товарищей, которые ничего кроме школьных задачек и не решали. Дело в масштабируемости. Чем сложнее проект, тем круче нужны инструменты для его разработки. Благо у меня например опыта много в разработке почти без отладчика. Но корячится каждый раз с мелкими ошибками - это тоже не подарок. Однажды может не повезти и ты словишь сложную ошибку, которую трудно будет найти. Я тут недавно курьез словил. Дебагал ошибку три дня. Все было 100% ок, но не работало. Оказалось это баг в DOSBox. И я его нашел)))
     
     
  • 3.57, Anonymmm (?), 15:17, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    И как ядро Linux без ООП живёт)
     
     
  • 4.58, Аноним (55), 16:21, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Всё тяжелее.
     
  • 4.59, Andrey (??), 16:41, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Там своя кустарная реализация ООП на C.
     
  • 2.35, Аноним (30), 16:28, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >не свой код отлаживать, а чужой

    А зачем? Это же что-то вроде наказания

     
     
  • 3.38, Аноним (39), 16:54, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, есть такое понятие «надо».
    Во-вторых, есть такое понятие «реверс-инженеринг». И это куда интереснее, чем принтфы в своём коде расставлять, чтобы очередной унылый выход за границы массива искать.
     
     
  • 4.61, Аноним (-), 23:06, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    "Во-вторых" -- это не про gdb от слова вообще. gdb крайне неудобен для отладки бинарей без отладочной информации. И в целом обратная разработка -- это не разработка, там очень много чего по другому. Некоторые скиллы разработки оказываются полезными для обратной разработки, но большинство бесполезно. Некоторые инструменты для разработки, оказываются полезными для обратной разработки, но всё же основные инструменты обратной разработки уникальны для неё. Не надо путать тёплое с мягким.

    А "во-первых" это твои проблемы. Ты всегда можешь сменить место работы так, чтобы не было "надо". То есть, выходит что не надо, но ты сознательно на это идёшь.

     
  • 2.45, Аноним (32), 19:03, 19/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > а чужой? да не в исходниках, а в виде готовых бинарников?

    Это самая большая проблема - отлаживать чужой код. На кривой и убогий Qt у меня было убито 80% времени, потраченного на проект в целом. Впрочем, полгода назад нашел лучшее решение, забыв о нем, как о кошмарном сне.

     
     
  • 3.53, Аноним (53), 12:06, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Что за решение, если не секрет?
     
     
  • 4.54, Аноним (-), 12:23, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Что за решение, если не секрет?

    Электрон, разумеется!
    Все просто работает.

     
  • 2.50, Аноним (19), 04:01, 20/01/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мы же на OPEN net. У нас код открытый.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2025 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру