- Сучасна розробка на Linux на C/C++ спирається на GCC, Clang/LLVM та такі рішення, як IBM Open XL C/C++, для створення оптимізованих, стандартизованих бінарних файлів.
- Ефективне налагодження в Linux поєднує в собі інтерфейси GDB, IDE та належну налагоджувальну інформацію DWARF, а не покладається виключно на інтеграції редакторів, таких як VS Code.
- Такі інструменти, як strace, ltrace, SystemTap та робочі процеси з дампами ядра доповнюють GDB, відкриваючи системні виклики, взаємодії бібліотек та стан після розкриття.
- Нещодавні зміни GDB та RHEL підвищують надійність, безпеку скриптів та пам'яті, роблячи масштабне налагодження C/C++ більш керованим та передбачуваним.
Якщо ви маєте досвід роботи з Windows + Visual Studio і раптом потрапляєте у величезну базу коду C або C++ на Linux, зміни можуть здатися жорстокими. Перегляд сотень тисяч рядків за допомогою GDB за редактором, таким як VS Code, чекаючи 30-60 секунд на кожен крок, може змусити вас задуматися, чи не робите ви щось жахливо неправильно, чи розробка під Linux просто повільна за своєю природою. Гарна новина полягає в тому, що сучасні набори інструментів та налагоджувачі Linux надзвичайно потужні; вам лише потрібно знати, як їх налаштувати та які інструменти підходять для великих проектів C/C++.
Цей посібник ознайомить вас з усіма аспектами компіляторів C/C++, IDE та інструментів налагодження в Linux., (подивитися Опануйте Linux з нуля), від GCC, Clang/LLVM та IBM Open XL C/C++ до GDB, Eclipse, SystemTap, strace, ltrace та розширених робочих процесів з дампами ядра. По дорозі ми також торкнемося класичних налаштувань навчання (таких як Geany + GCC) та покажемо конкретні поради щодо пришвидшення налагодження та наближення розробки Linux на C та C++ до комфорту, до якого ви, можливо, звикли у Windows.
Компілятори для C та C++ на Linux: GCC, Clang/LLVM та IBM Open XL
У Linux довідковим інструментарієм для C та C++ все ще є GCC (GNU Compiler Collection), а g++ — його інтерфейс для C++. Більшість дистрибутивів постачають GCC за замовчуванням, і практично всі навчальні посібники, системи збірки та конвеєри неперевершеної інтеграції передбачають його наявність. Зазвичай компіляція здійснюється за допомогою таких команд, як gcc для C та g++ для C++, наприклад g++ -g -O2 main.cpp -o app створити налагоджуваний, оптимізований бінарний файл.
Clang та екосистема LLVM перетворилися на потужну альтернативу GCC у Linux., що пропонує швидку компіляцію, чудову діагностику та багатий набір інструментів (статичний аналіз, форматування коду, санітарні засоби тощо). Clang — це фронтенд C/C++, побудований на основі LLVM, модульної інфраструктури компіляторів з відкритим кодом, яка підтримує різні архітектури та мови програмування та активно підтримується великою спільнотою.
IBM Open XL C/C++ для Linux на Power — це комерційний набір інструментів, який тісно інтегрує Clang/LLVM з багаторічним досвідом IBM в оптимізації компіляторів. Орієнтований на системи IBM Power, він використовує сучасні функції мови C/C++ (включаючи C++17), стандартні оптимізації LLVM та сумісність з GCC для створення високопродуктивних бінарних файлів на обладнанні Power. Це означає, що ви отримуєте переваги екосистеми LLVM, а також оптимізації, налаштовані на платформу, розроблені IBM.
Для застарілих середовищ IBM все ще надає старіші компілятори XL C/C++ для Linux., тож організації з існуючими ланцюжками збірки або обмеженнями сертифікації можуть продовжувати використовувати їх, поступово впроваджуючи Open XL C/C++ для нових робочих навантажень.
Класична система навчання: GCC та легкі IDE
Якщо ви тільки починаєте працювати з C або C++ у Linux, дуже поширеною та ефективною конфігурацією є GCC разом із легким IDE, таким як Geany. Geany є кросплатформним (Linux та Windows), швидким та інтегрує базові функції, такі як управління проектами, команди збірки та просте налагодження, без накладних витрат повноцінних важких IDE.
Багато довгих курсів з C/C++ для Linux рекомендують саме таку комбінацію: GCC як компілятор та Geany як середовище розробки. За допомогою таких навчальних посібників ви зазвичай вивчаєте мову з нуля: що таке компілятор GNU та як його викликати, як структурувати програму, як працювати з умовними операторами, функціями, масивами, рядками, вказівниками, структурами, об'єднаннями, файловим вводом/виводом і, зрештою, об'єктно-орієнтованими концепціями, такими як успадкування, перевантаження операторів та поліморфізм у C++.
Хоча вибір IDE різниться, базова порада щодо інструментарію, як правило, є послідовною: використовуйте GCC (або g++) на різних платформах, коли це можливо. У Linux це налаштування за замовчуванням; у Windows та macOS ви можете встановити GCC через MinGW, MSYS2, WSL, Homebrew або подібні інструменти, що забезпечує однаковий робочий процес у всіх системах та спрощує обмін скриптами та Makefile.
Навіть коли IDE абстрагує кроки збірки, розуміючи, що вона просто викликає gcc or g++ за лаштунками є критично важливим для налагодження складних проблем збірки або виконання. Варіанти, як -g для налагоджувальної інформації, рівні оптимізації, такі як -O0, -O2 or -O3та прапорці для налаштування попереджень або відповідності стандартам (-Wall, -std=c++17тощо) мають велике значення при діагностиці ледь помітних помилок.
Налагодження у великих кодових базах C++: від VS Code до нативного GDB
Розробники, які переходять з Visual Studio на Windows на Linux, часто починають з Visual Studio Code та розширення на основі GDB і швидко помічають, що запуск налагоджувача може стати надзвичайно повільним на великих серверних системах. Нерідко трапляються випадки затримок у 30-60 секунд на кожному кроці під час налагодження великих систем обробки або доставки документів із сотнями тисяч рядків та багатьма компонентами серверної частини.
Така повільна робота зазвичай є обмеженням не самого GDB, а рівня інтеграції або конфігурації між VS Code та базовим налагоджувачем. Проблеми в розширенні налагодження, синхронізації точок зупинки, завантаженні інформації про символи та перетворенні команд MI (машинного інтерфейсу) можуть сприяти значному уповільненню роботи складних реальних програм.
У розширенні VS Code C/C++ повідомлялося про давні проблеми, пов'язані з продуктивністю покрокового виконання з GDB у Linux. Для деяких команд це означає, що VS Code чудово підходить як редактор, але не обов'язково є найшвидшим варіантом як фронтенд для налагодження монструозних сервісів C++; такі альтернативи, як IDE Google Antigravity і існують нативні IDE. Коли продуктивність критично важлива, багато інженерів повертаються до використання GDB безпосередньо або переходять на нативне IDE, більш глибоко інтегроване з локальним інструментарієм.
Отже, якщо ви виявите, що кожен крок у вашому сеансі налагодження VS Code на Linux займає півхвилини, не думайте, що налагодження Linux за своєю суттю таке повільне. Перш ніж здаватися, варто протестувати GDB безпосередньо в терміналі на тому ж бінарному файлі та порівняти поведінку. Часто вхід у GDB значно швидший, що вказує на вузьке місце конфігурації або розширення, а не на фундаментальну проблему ОС чи компілятора.
У великих магазинах C++ на Linux популярними альтернативами для комфортного налагодження є Eclipse з CDT (інструменти розробки C/C++), CLion, Qt Creator, KDevelop та інші нативні IDE, які тісніше інтегруються з GDB та локальною системою. Ці середовища можуть забезпечувати навігацію по вихідному коду, вікна спостереження та розширені точки зупинки, водночас використовуючи GDB «під капотом» без накладних витрат на рівні налагодження, незалежні від мови.
Інформація про налагодження в Linux: ELF, DWARF, debuginfo та debugsource
У Linux скомпільовані програми та спільні бібліотеки зазвичай зберігаються у файлах ELF (Executable and Linkable Format), а пов'язана з ними налагоджувальна інформація закодована у форматі DWARF. DWARF містить метадані, необхідні налагоджувачам для зіставлення машинного коду з вихідними файлами, номерами рядків, функціями, типами та змінними.
Ви можете перевірити розділи DWARF у двійковому файлі ELF за допомогою таких інструментів, як readelf -w file, який виводить необроблені записи налагодження. Хоча зазвичай ви не читаєте DWARF вручну, це підтверджує наявність налагоджувальної інформації та може бути безцінним для діагностики проблем типу «немає завантажених символів» у GDB або інших інструментах.
Старіший формат налагодження під назвою STABS все ще існує, але вважається застарілим і не рекомендується використовувати в сучасних дистрибутивах Linux, таких як Red Hat Enterprise Linux. GCC та GDB забезпечують найкращу підтримку для STABS, але ключові інструменти в екосистемі (наприклад, Valgrind або elfutils) можуть працювати з ними неправильно, тому наполегливо рекомендується використовувати DWARF.
Оскільки дані налагодження зазвичай великі, більшість дистрибутивів розділяють їх з основних бінарних файлів на окремі пакети debuginfo та debugsource. Виконуваний файл, який ви встановлюєте зі стандартного репозиторію, зазвичай позбавляється символів налагодження, щоб заощадити місце на диску та зменшити обсяг пам'яті, тоді як відповідний пакет debuginfo містить дані DWARF, а debugsource, за бажанням, включає відповідні вихідні коди.
У RHEL та подібних системах ви явно запитуєте налагоджувальну інформацію під час компіляції, використовуючи -g під час створення власних проектів за допомогою GCC. Для системних та сторонніх бібліотек, встановлених з пакетів, ви можете отримати відповідні debuginfo та debugsource пакети зі спеціалізованих репозиторіїв налагодження, часто на які GDB безпосередньо вказує, коли помічає відсутні символи під час сеансу налагодження.
Встановлення та пошук debuginfo для системних бінарних файлів
Під час налагодження програм на C або C++, які залежать від системних бібліотек, встановлення debuginfo для цих бібліотек може суттєво вплинути на якість зворотних трасування та перевірки змінних. Без нього ви бачите лише необроблені адреси або спотворені назви функцій у спільних бібліотеках; з ним ви отримуєте точні до рядка трасування стеку та символічні назви змінних.
У дистрибутивах, подібних до RHEL, GNU Debugger (GDB) може автоматично виявляти відсутність налагоджувальної інформації для завантаженого об'єкта та пропонувати конкретну команду для встановлення необхідної інформації. debuginfo пакет через dnf. Ви просто виконуєте рекомендовану dnf debuginfo-install ... команду, підтвердіть її, коли буде запропоновано, і система отримає та встановить пакети символів, необхідні для вашого сеансу.
Якщо автоматичні підказки недоступні, ви можете вручну визначити потрібну налагоджувальну інформацію, знайшовши бінарний файл або файл бібліотеки за допомогою таких інструментів, як locate а потім запит до бази даних RPM. Команда locate команда надходить від mlocate пакет, який вам, можливо, знадобиться встановити та ініціалізувати, і після того, як ви отримаєте шлях, ви можете запитати, якому пакету він належить, а потім встановити відповідний варіант debuginfo.
Бувають ситуації, коли пакет, який встановив певний бінарний файл, неможливо визначити, наприклад, коли файл був скопійований вручну або зібраний на місці без пакування. У таких випадках вам може знадобитися повернутися до користувацьких файлів символів або, якщо можливо, самостійно перебудувати бінарний файл за допомогою -g увімкнено, щоб GDB мав повні дані налагодження.
Пам'ятайте, що встановлення debuginfo для кожної окремої бібліотеки в системі рідко буває необхідним і може бути марнотратним. Зосередьтеся на модулях, які найбільше відповідають вашій проблемі: бінарних файлах вашої програми та конкретних бібліотеках, з яких виникає збій або неправильна поведінка, замість того, щоб витягувати пакети налагодження для всієї ОС.
Використання GDB для інтерактивного налагодження в Linux
GDB — це центральний інструмент для налагодження рідних програм C та C++ у Linux, що надає як інтерфейс командного рядка, так і, через інтеграції, графічні інтерфейси, такі як Eclipse CDT. У Red Hat Enterprise Linux стандартний дистрибутив включає повнофункціональну GDB разом із додатковими графічними інтерфейсами.
Для налагодження програми з самого початку зазвичай викликається gdb ./program, налаштуйте точки зупинки за потреби, а потім запустіть виконання всередині GDB за допомогою run команда Або ж ви можете підключитися до програми, яка вже працює разом із gdb -p <pid> або запустивши GDB та використовуючи attach команду разом з ідентифікатором процесу.
Якщо GDB не може визначити цільовий виконуваний файл для заданого PID під час підключення, ви можете явно вказати йому, який бінарний файл використовувати, через file команду, а потім перейдіть до налагодження. Це особливо корисно, коли ви маєте справу з користувацькими програмами запуску, скриптами-обгортками або багатобінарними конфігураціями, де фактичний шлях до виконуваного файлу неочевидний.
Після підключення або запуску ви керуєте виконанням програми за допомогою таких команд, як n (далі), s (крок), until, finish і просто c (продовжити), виходячи з налагоджувача за допомогою q коли закінчено Кожна з цих команд має певну семантику щодо того, чи вона переходить у тіла функцій, виконується до певного рядка чи відновлює виконання до наступної точки зупинки або завершення.
Для розуміння стану GDB надає розширені команди інтроспекції для перевірки змінних, стеків викликів, регістрів тощо, а також пропонує контекстну довідку через help info та подібні команди. Ви можете показати поточний рядок вихідного коду за допомогою list, вивести змінні за допомогою print, досліджуйте стекові фрейми за допомогою backtrace та навігації по кадрах за допомогою frame, up та down.
Точки зупинки, точки спостереження та умови в GDB
У реальному налагодженні ви майже ніколи не відходите від main(); натомість ви стратегічно розміщуєте точки зупинки, щоб зупинити програму саме там, де її поведінка стає цікавою. Стандартна команда break дозволяє встановлювати точки зупинки або за номером файлу та рядка, або за назвою функції, а GDB призупинить виконання при наступному зверненні.
Наприклад, ви можете встановити точку зупинки на певному рядку вихідного коду, використовуючи такий синтаксис, як break file.cpp:123або перервати на початку функції за допомогою break my_function. Коли досягнуто точки зупинки, GDB зупиняє програму, дозволяючи вам перевірити локальні змінні, перевірити стек викликів та вирішити, чи слід втрутитися, переступити позначку або продовжити.
Умовні точки зупинки безцінні, коли помилка з'являється лише після багатьох ітерацій або за певних вхідних значень. Ви можете пов'язати булеву умову, написану на C або C++, з точкою зупинки, щоб GDB зупинявся лише тоді, коли умова має значення true, що значно зменшує кількість непотрібних зупинок і робить цикли налагодження або складні кінцеві автомати набагато ефективнішими.
Для моніторингу змін у даних, а не в процесі коду, GDB пропонує точки спостереження, які спрацьовують, коли вираз (часто змінна) зчитується або записується в неї. З такими командами, як watch, rwatch (читати) або awatch (читання/запис), ви можете зупинити виконання саме тоді, коли певне поле змінюється або до нього звертається, що особливо корисно для відстеження неочікуваних змін стану.
Ви керуєте всіма точками зупинки та точками спостереження за допомогою таких команд, як info breakpoints or info br, а видаляти можна за номером або за місцем розташування, використовуючи delete з відповідними аргументами. Це дозволяє легко підтримувати чистий набір активних точок зупинки та запобігати плутанині під час налагодження кількох модулів або сеансів.
Налагодження багатопотокових та роздвоєних процесів
Налагодження програм на C та C++, які широко використовують потоки або розгалуження, вимагає додаткового розуміння того, як GDB відстежує контексти виконання. За замовчуванням GDB позначає поточний потік, і більшість команд працюють у цьому потоці, якщо ви явно не перемикаєте його за допомогою thread та ідентифікатор потоку.
Коли ваша програма розгалужується, налаштування set detach-on-fork визначає, чи GDB слідує за дочірнім чи батьківським процесом, і як він обробляє процес, за яким не слідкують. Ви можете налаштувати GDB або для контролю обох, або для автоматичного відключення від однієї сторони, залежно від того, чи є батьківський, дочірній або обидва релевантними для вашого аналізу.
У новіших версіях GDB було вдосконалено спосіб нумерації потоків, запроваджуючи ідентифікатор для кожного нижчого потоку разом з окремим глобальним ідентифікатором потоку для сумісності. Змінна зручності $_thread та API Python InferiorThread.num тепер відображає нумерацію для кожного нижчого рівня, тоді як глобальний ідентифікатор доступний через $_gthread та InferiorThread.global_num, що забезпечує подальшу роботу старих інструментів на основі глобальних ідентифікаторів.
Обробку сигналів у багатопотоковому налагодженні також покращено, щоб сигнали завжди доставлялися до правильного потоку. Якщо ви зміните потік після того, як сигнал зупиняє програму, а потім спробуєте продовжити, GDB може запросити підтвердження, запобігаючи випадковій помилковій доставці та підвищуючи надійність налагодження, пов'язаного з сигналами.
Все це означає, що під час аналізу взаємоблокувань, перегонів або дивних збоїв, спричинених сигналами, ви можете покладатися на модель потоків GDB для відстеження правильного шляху виконання з точним контролем. У поєднанні з точками зупинки, точками спостереження та точками перехоплення це забезпечує надійне багатопотокове налагодження навіть у високопаралельних сервісах C++.
Виклики системи трасування та бібліотек: strace, ltrace та SystemTap
Іноді найшвидший спосіб зрозуміти, чому програма на C або C++ поводиться неправильно, — це не переглядати кожен рядок, а спостерігати, як вона взаємодіє з операційною системою та її спільними бібліотеками. Linux пропонує кілька потужних інструментів для цього: strace, ltrace, SystemTap і навіть сам GDB через спеціалізовані точки збору.
Команда strace Утиліта відстежує системні виклики — взаємодії з ядром, такі як open, read, write, mmap, execve і так далі — разом з їхніми параметрами та значеннями, що повертаються. Ви можете запустити свою програму через strace або приєднатися до запущеного процесу за PID, опціонально фільтруючи, які системні виклики відображати, використовуючи вирази типу -e trace=call та керування тим, чи слід слідувати за розгалуженими чи потоковими дочірніми елементами, за допомогою -f.
Оскільки реальні програми виконують величезну кількість системних викликів, поєднуючи strace з інструментами оболонки, такими як tee є поширеним як переглядом виводу в реальному часі, так і його збереженням для аналізу. Це допомагає виявити відсутні файли, проблеми з дозволами, неочікувану поведінку мережі або інші проблеми на рівні ОС, які можуть бути неочевидними з самого коду.
Доповнюючи strace, ltrace зосереджена на викликах функцій спільної бібліотеки в просторі користувача, показуючи виклики та значення, що повертаються, для експортованих функцій з динамічних об'єктів. У RHEL 8 існує відоме обмеження, через яке ltrace не може відстежувати певні системні виконувані файли, але він працює нормально для користувацьких бінарних файлів, що робить його цінним інструментом для розуміння того, як ваша програма використовує API бібліотек.
SystemTap — це більш просунутий фреймворк трасування, який дозволяє створювати власні обробники подій як для ядра, так і для подій простору користувача, використовуючи власну мову сценаріїв. Його використання може бути складнішим, ніж strace або ltrace, але він краще масштабується та підтримує складну фільтрацію та агрегацію. Для зручності, приклад скрипта під назвою strace.stp постачається із SystemTap для імітації поведінки, подібної до strace, використовуючи інфраструктуру SystemTap.
Сам GDB може брати участь у трасуванні, використовуючи точки спостереження для системних викликів та сигналів за допомогою таких команд, як catch syscall та catch signal. Це призводить до зупинки виконання налагоджувача щоразу, коли програма виконує певні системні виклики або отримує певні сигнали, що може бути дуже зручно, коли вам потрібен детальний контроль під час інтерактивного налагодження.
Дампи основних даних та налагодження після розшифровки за допомогою GDB
Коли програма на C або C++ аварійно завершує роботу або зависає таким чином, що важко відтворити інтерактивно, дампи основних даних надають знімок її пам'яті та стану в критичний момент. Дамп ядра — це ELF-файл, що містить вміст частин пам'яті процесу (стек, купа, маппінги) під час завершення, який ви можете проаналізувати пізніше за допомогою GDB, ніби ви були підключені під час аварійного завершення.
Щоб ефективно використовувати дампи основних даних, необхідно переконатися, що вони дійсно генеруються та не блокуються обмеженнями ресурсів або конфігурацією. Обмеження оболонки, такі як ulimit -c може запобігти створенню основних файлів; встановлення обмеження на unlimited знімає обмеження розміру, хоча слід переглянути наслідки для дискового простору у виробничих системах.
У сучасних системах RHEL, systemd-coredump прозоро керує основними дампами та зберігає їх у централізованому місці, подібному до журналу, замість того, щоб залишати core файли, розкидані по каталогах. Команда coredumpctl Інструмент дозволяє переглядати записані збої, перевіряти їхні метадані та експортувати фактичний файл ядра за вибраним шляхом для глибшого аналізу.
Під час створення систематичного робочого процесу фіксації збоїв зазвичай встановлюють sos упаковка та використання sosreport створити tar-архів із конфігурацією системи та журналами. У поєднанні з експортованим основним файлом та бінарними файлами програми це надає вам усе необхідне для аналізу збоїв на окремій машині або передачі їх іншій команді чи постачальнику.
Ви навіть можете навмисно запустити дамп ядра для процесу, який не відповідає, надіславши йому сигнал переривання або використовуючи такі інструменти, як gcore, які скидають пам'ять процесу під час його роботи. Під час gcore dump, процес ненадовго призупиняється, а потім відновлює нормальне виконання, що дозволяє проводити офлайн-аналіз проблемного стану без повного завершення служби.
Пошук правильного виконуваного файлу та символів для аналізу ядра
Для змістовного аналізу дампу ядра GDB потрібен як файл ядра, так і точний виконуваний файл (плюс будь-які відповідні спільні бібліотеки), який його створив. Це важливо, оскільки невідповідні бінарні файли, зібрані з різних версій, можуть призвести до оманливих зворотних трас і неправильного розташування змінних.
Такі інструменти, як coredumpctl info показати детальні метадані для кожного захопленого ядра, включаючи шлях до основного виконуваного файлу та ідентифікатор збірки, який унікально ідентифікує бінарний файл. Ідентифікатор збірки може виглядати як довгий шістнадцятковий хеш, і ви можете порівняти його з ідентифікатором збірки вашої локальної копії бінарного файлу, щоб переконатися, що вони ідентичні, перш ніж запускати GDB.
Якщо виконуваний файл та його бібліотеки походять з RPM-пакетів, ви можете використовувати sosreport та базу даних пакетів для отримання точних необхідних версій. У деяких випадках ви навіть можете перевстановити відповідні пакети на виділеній машині для налагодження, а потім використовувати GDB. set sysroot конфігурацію, щоб вказати на дзеркальне відображення бібліотеки для віддаленого налагодження.
Після отримання правильних об'єктів ви запускаєте сеанс GDB за допомогою такої команди, як gdb /path/to/exe /path/to/core і дозвольте GDB завантажити ядро. Якщо для будь-яких модулів відсутня інформація про налагодження (debuginfo), GDB відображатиме повідомлення з підказками щодо того, які пакети або файли символів слід встановити, щоб отримати повну видимість символів.
Якщо символи налагодження вашої програми надаються в окремих файлах, а не через пакети, ви можете завантажити їх явно за допомогою symbol-file команда всередині GDB. Ви не зобов'язані мати налагоджувальну інформацію для кожної окремої спільної бібліотеки в ядрі; зосередження на власному застосунку та підозрілих бібліотеках зазвичай достатньо для реконструкції відповідного стеку та стану.
Аналізуючи дамп основного процесу, пам'ятайте, що команди для керування виконанням програми (такі як step або continue) більше не мають сенсу, оскільки до них не приєднано активний процес. Натомість, ви покладаєтеся на команди перевірки — вивчення стекових фреймів, локальних та глобальних змінних, областей пам'яті та потоків — щоб визначити, чому стався збій або де програма застрягла.
Розширені сценарії створення дампа пам'яті та зміни GDB на сучасному RHEL
Деякі програми з високим рівнем безпеки або високою продуктивністю позначають частини своєї пам'яті як такі, що не підлягають дампу, за допомогою таких прапорців, як VM_DONTDUMP, що запобігає запису цієї пам'яті в основні файли. Це захищає конфіденційні дані (наприклад, криптографічні ключі або фінансові записи) та зменшує розміри дампів, але ускладнює повний офлайн-аналіз.
Якщо у вас є сильна потреба захопити все, включаючи області, які зазвичай виключаються зі створення дампів, ви можете налаштувати GDB так, щоб він ігнорував прапорець "не створювати дамп" і примусово створив повний дамп пам'яті. GDB надає опції для перевизначення VM_DONTDUMP і вивести всю пам'ять процесу в основний файл для проведення експертизи або глибокого налагодження.
Що стосується інструментарію, версія GDB, що постачається з RHEL 8, вносить низку змін у поведінку та порушення роботи системи порівняно з RHEL 7, особливо в тих областях, де раніше користувачі аналізували вивід терміналу. Замість того, щоб виводити текст, Red Hat рекомендує писати скрипти, використовуючи Python API GDB або протокол Machine Interface (MI), обидва з яких призначені для програмного використання.
Серед помітних змін – запуск підлеглих серверів GDBserver через оболонку для розширення аргументів, видалення підтримки GCJ (Java), оновлений синтаксис для команд символьного дампу обслуговування та корекції обробки системного кореня для кращої підтримки віддаленого налагодження. Деякі команди та режими, такі як сумісність HP-UX XDB та remotebaud, були виведені з експлуатації або замінені більш загальними еквівалентами, такими як set serial baud.
Крім того, GDB запровадив такі обмеження, як max-value-size щоб запобігти необмеженому розподілу пам'яті під час друку дуже великих значень, змінено спосіб керування розміром історії команд через GDBHISTSIZE замість HISTSIZEта додано обмеження на кількість кандидатів на завершення через set max-completions. Ці запобіжні заходи допомагають уникнути зависань або надмірного споживання пам'яті під час налагодження патологічних або пошкоджених програм.
Кінцевим результатом для розробників C та C++ у Linux є більш надійний, скриптовий налагоджувач, який масштабується до величезних кодових баз та дивних сценаріїв збоїв, за умови, що ви знаєте про оновлені команди та ручки налаштування. У поєднанні із сучасними інфраструктурами компіляторів, такими як GCC та Clang/LLVM (і такими пропозиціями, як IBM Open XL C/C++ на Power), GDB утворює основу потужного інструментарію для розробки та усунення несправностей складного нативного програмного забезпечення в Linux.
Вибір правильного компілятора та IDE, увімкнення налагоджувальної інформації DWARF та встановлення пакетів debuginfo, а також використання робочих процесів GDB, strace, ltrace, SystemTap та core-dump забезпечують швидке, прозоре та придатне для найбільших серверних систем середовище Linux C/C++, навіть якщо ваші перші враження були отримані після повільного сеансу налагодження VS Code. Завдяки правильній конфігурації та обізнаності з доступними інструментами, налагодження в Linux не лише відповідає комфорту Visual Studio у Windows; у багатьох випадках воно фактично надає вам точніший контроль та глибше розуміння того, як насправді поводяться ваші програми на C та C++.
