Комментарии 27
На случай, если кто-то задумается: "Блин, хочу такое же, но я на Линуксе". Оно есть (во всяком случае, похожее). Есть упоминания о reverse debug в GDB (там записывается каждая выполненная инструкция). Также есть эпичный проект от Mozilla: rr — он записывает только недетерминированное поведение (системные вызовы, rdtsc, ...) и имеет некоторые ограничения (в частности, работает, насколько я помню, только под Linux и на относительно свежих процессорах от Intel; недавно, вроде, пытались добавить поддержку AMD Ryzen, интересно, чем закончилось) — заявляется оверхед на запись чуть ли не x1.5 и меньше. В QEMU тоже, вроде, какой-то record-replay добавляли...
Тоже хотел про rr написать, классная штука. Кроме этого есть CLion и еще несколько проприетарных отладчиков с этой функцией (они быстрее gdb). В свое время на винде мне этого не хватало, и вот наконец появилось.
Кроме этого есть CLion и еще несколько проприетарных отладчиков с этой функцией (они быстрее gdb).Осталось понять как CLion, в котором отладка выполнена через вызов gdb, смог работать быстрее, чем сам gdb.
Удобнее — верю. Быстрее — нет.
Нет, те что быстрее это из «еще несколько проприетарных». Я не помню уже какие именно пробовал, но что то типа таких undo.io/products/undodb, если поискать можно еше несколько аналогичных найти. Вот из них на то время точно были быстрее стокового gdb. Сейчас уже обычно rr хватает, с ним никаких проблем по скорости.
Процессор должен быть начиная с Core 2 Duo.
А вот в виртуалке будет работать, только если она поддерживает виртуализацию PMU.
А вот в виртуалке будет работать, только если она поддерживает виртуализацию PMU.
Протокол отладки опять несовместим? Опять везде переставлять dbgsrv( удаленно кстати не работает
А IDA или radare уже совместимы?
прикольно.
Можно ли ожидать появления такой же функции в Visual Studio?
в VS 2017 Update 5 будет)
В VS2017 вроде убрали такое понятие как update выпуски или я неправ? теперь она сама вроде предлагает обновиться
Да, имелась в виду версия 15.5)
Так вроде для шарпа есть уже пару версий что-то схожее… Или вопрос про С\С++?
Жаль только, что в 7ке этого не получить. Они написали, что TTD выйдет в следующем SDK для 7ки, но когда это будет — не знаю.
Слушайте, а бывает в отладчиках такая функция (и если бывает, то как называется?):
выбираю два момента времени по мере работы программы → получаю в дизассемблерном листинге подсвеченными именно те инструкции, которые выполнялись между этими двумя моментами времени?
выбираю два момента времени по мере работы программы → получаю в дизассемблерном листинге подсвеченными именно те инструкции, которые выполнялись между этими двумя моментами времени?
Смотрю я на эту новость… и ловлю себя на мысли: а почему, собственно, я должен воспринимать это как «вау, как крута?»… Откройте мануал к старому древнему Turbo Debugger'у 2.0 1990го года выпуска — и вы увидите эту фичу в разделе «Controlling Program Execution», подраздел «Back Trace».
Вот только системные требования за четверть века выросли с пресловутых 640K, которых «хватит всем» (хотя, конечно в TD.EXE back trace был очень ограниченный, для комфортной работы тогда требовались «огроменнейшие» 2-4MB) до 2-4GB, то есть более, чем в 1000 раз… и процессор требуется в 2000-4000 раз более мощный (номинальные частоты отличаются почти в 1000 раз, а ведь 8086 одну команду исполнять мог чуть не 10 тактов)… и… где, чёрт побери, программная индустрия слетела с катушек?
P.S. Я ни в коем случае не умаляю достижений команды WinDbg. Охотно верю в то, что у них была масса сложностей, которые они успешно преодолели. Вопрос скорее философский. Почему фича, которая не казалось чем-то «вау» тогда… сегодня вдруг — повод для статьи на хабре? Почему мы в качестве новинок получаем то, что уже имели четверть века назад — пусть и новыми, более красивыми кнопочками?
Вот только системные требования за четверть века выросли с пресловутых 640K, которых «хватит всем» (хотя, конечно в TD.EXE back trace был очень ограниченный, для комфортной работы тогда требовались «огроменнейшие» 2-4MB) до 2-4GB, то есть более, чем в 1000 раз… и процессор требуется в 2000-4000 раз более мощный (номинальные частоты отличаются почти в 1000 раз, а ведь 8086 одну команду исполнять мог чуть не 10 тактов)… и… где, чёрт побери, программная индустрия слетела с катушек?
P.S. Я ни в коем случае не умаляю достижений команды WinDbg. Охотно верю в то, что у них была масса сложностей, которые они успешно преодолели. Вопрос скорее философский. Почему фича, которая не казалось чем-то «вау» тогда… сегодня вдруг — повод для статьи на хабре? Почему мы в качестве новинок получаем то, что уже имели четверть века назад — пусть и новыми, более красивыми кнопочками?
«Turbo Debugger can record about 400
instructions. If you have EMS, it can record approximately 3000
instructions. » вобщем не то это было. Оно не писало трассу всего приложения а просто хранило историю инструкций, эту историю мог 1 большой цикл сожрать за раз. А step back в пределах фрейма без сохранения истории для последующего анализа есть и сейчас в msvs
instructions. If you have EMS, it can record approximately 3000
instructions. » вобщем не то это было. Оно не писало трассу всего приложения а просто хранило историю инструкций, эту историю мог 1 большой цикл сожрать за раз. А step back в пределах фрейма без сохранения истории для последующего анализа есть и сейчас в msvs
«Трасса всего приложения» всегда ограничена. Если я Хром запущу, который сейчас у меня по счётчику отработал 30 часов — думаете он трассу сможет куда-нибудь записать? И в те времена TD сохранить трассу для реального приложения не мог, и сейчас WinDbg не сможет.
А поскольку в те времена 100 слоёв обёрток не наворачивали, то 3000 инструкций хватало для очень и очень многого. Какой-нибудь memcpy — это пяток инструкций был. И strcmp тоже. И многое другое было резко короче, чем сегодня…
А поскольку в те времена 100 слоёв обёрток не наворачивали, то 3000 инструкций хватало для очень и очень многого. Какой-нибудь memcpy — это пяток инструкций был. И strcmp тоже. И многое другое было резко короче, чем сегодня…
Если я Хром запущу, который сейчас у меня по счётчику отработал 30 часов — думаете он трассу сможет куда-нибудь записать?
rr, например, как раз и создавался для записи реального приложения — Mozilla Firefox. Записывать им трассу на 30 часов не практично, конечно. Записать 30 минут — час совершенно не проблема. Ограничение здесь даже не дисковое пространство — его-то как раз хватит, а время на перемотку. Вот если допилят снапшоты, то и 30 часов не будет большой проблемой.
TTD, если мне не изменяет память, по дисковым требованиям похож на rr.
Откройте мануал к старому древнему Turbo Debugger'у 2.0 1990го года выпуска — и вы увидите эту фичу в разделе «Controlling Program Execution», подраздел «Back Trace».
Вы сравниваете несравнимые вещи. В этом же мануале написано:
Some restrictions apply. See the section, «The Instructions pane (page 86).»
The execution history only keeps track of instructions that have
been executed with the Trace Into command (Fl) or the Instruction
Trace command (AIt-Fl). It also tracks for Step Over, as long as you
don't encounter one of the commands listed on page 84. As soon
as you use the Run command or execute an interrupt, the
execution history is deleted. (It starts being recorded again as
soon as you go back to tracing.)
Иными словами Trace Back в Turbo Debugger — это банальный undo для выполненных вручную шагов по коду. В случае однопоточной программы реализуется тривиально запоминанием контекста процессора на каждом шаге.
TTD — это полноценная записть состояния процесса для всех его потоков. Если делать такую запись в лоб — получаются жуткие тормоза: меденно (так как эмулируется каждая инструкция) и количество данных зашкаливает. Поэтому хорошие реализации хитрят (что TTD, что rr) — избегая необходимости сохранять более 99% состояния.
На самом деле, TTD — это технология 10-летней давности. Просто Microsoft решила наконец её выпустить в мир: www.usenix.org/legacy/events/vee06/full_papers/p154-bhansali.pdf.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Time Travel Debugging в новом WinDbg