GDB выпустила новую версию, которая поддерживает обратную отладку (см. Http://www.gnu.org/software/gdb/news/reversible.html ). Мне стало интересно, как это работает.
Чтобы заставить работать обратную отладку, мне кажется, что вам нужно хранить все состояние машины, включая память для каждого шага. Это значительно снизит производительность, не говоря уже об использовании большого количества памяти. Как решаются эти проблемы?
reverse-debugging
Натан Феллман
источник
источник
Ответы:
Я сопровождаю GDB и являюсь одним из авторов новой обратной отладки. Буду рад рассказать, как это работает. Как предполагали некоторые люди, вам нужно сохранить достаточно состояния машины, чтобы вы могли восстановить его позже. Существует ряд схем, одна из которых заключается в простом сохранении регистров или ячеек памяти, которые изменяются каждой машинной командой. Затем, чтобы «отменить» эту инструкцию, вы просто возвращаете данные в эти регистры или ячейки памяти.
Да, это дорого, но современные процессоры настолько быстры, что, когда вы все равно интерактивны (выполняете пошаговые инструкции или точки останова), вы на самом деле этого не замечаете.
источник
next
иstep
команды, которые вы ввели, или позволяет отменить любое количество инструкций? Например, если я установлю точку останова для инструкции и позволю ей работать до тех пор, могу ли я затем вернуться к предыдущей инструкции, даже если я пропустил ее?Обратите внимание, что вы не должны забывать об использовании симуляторов, виртуальных машин и аппаратных записывающих устройств для реализации обратного выполнения.
Еще одно решение для его реализации - это отслеживание выполнения на физическом оборудовании, как это делают GreenHills и Lauterbach в их аппаратных отладчиках. Основываясь на этой фиксированной трассировке действия каждой инструкции, вы можете затем перейти к любой точке трассировки, по очереди удаляя эффекты каждой инструкции. Обратите внимание: это предполагает, что вы можете отслеживать все, что влияет на состояние, видимое в отладчике.
Другой способ - использовать метод контрольной точки + повторное выполнение, который используется в VmWare Workstation 6.5 и Virtutech Simics 3.0 (и более поздних версиях) и который, похоже, будет поставляться с Visual Studio 2010. Здесь вы используете виртуальную машину или симулятор чтобы получить уровень косвенного доступа к выполнению системы. Вы регулярно выгружаете все состояние на диск или в память, а затем полагаетесь на способность симулятора детерминированно повторно выполнить тот же самый путь к программе.
Проще говоря, это работает так: скажем, что вы находитесь в момент времени T в исполнении системы. Чтобы перейти к моменту T-1, вы выбираете некоторую контрольную точку из точки t <T, а затем выполняете (Tt-1) циклы, чтобы закончить на один цикл раньше, чем вы были. Это можно заставить работать очень хорошо и применяться даже к рабочим нагрузкам, которые выполняют дисковый ввод-вывод, состоят из кода уровня ядра и выполняют работу с драйверами устройства. Ключ в том, чтобы иметь симулятор, который содержит всю целевую систему со всеми ее процессорами, устройствами, памятью и вводом-выводом. См. Список рассылки gdb и обсуждение после этого в списке рассылки gdb для получения более подробной информации. Я сам довольно регулярно использую этот подход для отладки сложного кода, особенно в драйверах устройств и при ранней загрузке ОС.
Еще один источник информации - это технический документ Virtutech по контрольным точкам (который я написал с полным раскрытием).
источник
Во время сеанса EclipseCon мы также спросили, как они это делают с помощью Chronon Debugger для Java. Это не позволяет вам фактически отступить, но может воспроизвести выполнение записанной программы таким образом, что это будет похоже на обратную отладку. (Основное отличие состоит в том, что вы не можете изменить запущенную программу в отладчике Chronon, в то время как вы можете сделать это в большинстве других отладчиков Java.)
Если я правильно понял, он манипулирует байтовым кодом запущенной программы, так что каждое изменение внутреннего состояния программы записывается. Дополнительные записи внешних состояний не требуется. Если они каким-то образом влияют на вашу программу, тогда у вас должна быть внутренняя переменная, соответствующая этому внешнему состоянию (и, следовательно, этой внутренней переменной достаточно).
Затем во время воспроизведения они могут воссоздать каждое состояние работающей программы из записанных изменений состояния.
Что интересно, изменения состояния намного меньше, чем можно было бы ожидать на первый взгляд. Итак, если у вас есть условный оператор if, вы можете подумать, что вам нужен хотя бы один бит для записи того, использовала ли программа оператор then или else. Во многих случаях вы можете избежать даже этого, например, в случае, когда эти разные ветки содержат возвращаемое значение. Тогда достаточно записать только возвращаемое значение (которое все равно понадобится) и пересчитать решение о выполненной ветке из самого возвращаемого значения.
источник
Хотя этот вопрос старый, большинство ответов тоже, и как обратная отладкаостается интересной темой, я отправляю ответ 2015 года. В главах 1 и 2 моей магистерской диссертации « Объединение обратной отладки и программирования в реальном времени в направлении визуального мышления в компьютерном программировании» рассматриваются некоторые исторические подходы к обратной отладке (особенно сфокусированные на подходе с использованием снимков (или контрольных точек) и воспроизведения) и объясняет разницу между этим и всеведущей отладкой:
источник
mozilla
rr
- более надежная альтернатива обратной отладке GDBhttps://github.com/mozilla/rr
Встроенная запись и воспроизведение GDB имеет серьезные ограничения, например, отсутствие поддержки инструкций AVX: обратная отладка gdb завершается неудачно с "Запись процесса не поддерживает инструкцию 0xf0d по адресу"
Плюсы р-р:
rr достигает этого, сначала запуская программу таким образом, чтобы записывать, что произошло при каждом недетерминированном событии, таком как переключение потока.
Затем во время второго прогона воспроизведения он использует этот файл трассировки, который на удивление мал, для точного восстановления того, что произошло в исходном недетерминированном прогоне, но детерминированным образом, в прямом или обратном направлении.
rr был первоначально разработан Mozilla, чтобы помочь им воспроизвести ошибки синхронизации, которые обнаружились во время их ночного тестирования на следующий день. Но аспект обратной отладки также важен, когда у вас есть ошибка, которая возникает только в течение нескольких часов после выполнения, поскольку вам часто нужно отступить, чтобы проверить, какое предыдущее состояние привело к последующему сбою.
Следующий пример демонстрирует некоторые из его особенностей, в частности
reverse-next
,reverse-step
иreverse-continue
команду.Установите на Ubuntu 18.04:
Программа испытаний:
скомпилировать и запустить:
Теперь вы остались внутри сеанса GDB, и вы можете правильно отменить отладку:
При отладке сложного программного обеспечения вы, скорее всего, дойдете до точки сбоя, а затем попадете в глубокий фрейм. В этом случае не забудьте, что для
reverse-next
более высоких кадров вы должны сначала:до этого кадра просто делать обычные
up
вещи недостаточно.На мой взгляд, наиболее серьезные ограничения rr:
UndoDB - коммерческая альтернатива rr: https://undo.io. Оба они основаны на трассировке / воспроизведении, но я не уверен, как они сравниваются с точки зрения функций и производительности.
источник
Натан Феллман писал:
Вы можете отменить любое количество инструкций. Вы не ограничены, например, остановкой только в тех точках, где вы остановились, когда двигались вперед. Вы можете установить новую точку останова и вернуться к ней.
Да. Пока вы включили режим записи до того, как дойдете до точки останова.
источник
Вот как работает другой обратный отладчик под названием ODB. Извлечь:
Я предполагаю, что GDB работает таким же образом.
источник
Обратная отладка означает, что вы можете запустить программу в обратном порядке, что очень полезно для выявления причины проблемы.
Вам не нужно сохранять полное состояние машины для каждого шага, только изменения. Вероятно, это все еще довольно дорого.
источник