Я не использовал MARSS / QEMU, но я знаком с этой проблемой, с симуляторами в целом и с SimpleScalar.
Очень сложно сделать полные системные симуляторы в целом детерминированными.Например, если ваша программа печатает время суток и время суток меняется, будут использоваться разные пути кода.В целом, если вы выполняете полное моделирование системы и время ls, то точное чередование ОС и кода пользователя будет отличаться в зависимости от положения головки диска, количества данных в кеше диска и т. Д. Не говоря уже о том, чтодругие процессы выполняются в системе.
SimpleScalar eio (и имитаторы в отрасли) обеспечивают детерминизм, регистрируя трассировку внешних событий ввода-вывода, которые применяются к моделированию с точно таким же количеством команд, как и в предыдущих запусках.По сути, вы выполняете полное моделирование системы только тогда, когда записываете
. Вам нужно искать похожие параметры для MARSS / QEMU.К сожалению, я не нашел таких.
Не хватает этих ...
Но я слышу, как вы говорите: "Моя программа не читает время суток. Разве она не должна работать точнотак же каждый раз? "Может быть и так ... но (1) многие библиотеки Linux делают моральный эквивалент чтения времени.И (2) существуют другие процессы, выполняющие пользовательский код.
Так что вам нужно контролировать пробег.Не загружайте свою виртуальную машину (не аппаратную виртуальную машину, я имею в виду только ОС, на которой вы работаете на симуляторе).Стоп в однопользовательском.Отредактируйте / etc / rc, чтобы остановить как можно больше запущенных процессов.Полная симуляция системы мало чем отличается от тестирования на реальной машине.А на реальных машинах мы можем даже перезагрузить машину каждый раз, когда запускаем тест.Отключить (виртуальную) сеть.И т. Д.
Если вы можете, не работайте на реальной ОС, а на минимальном мониторе.
Однако действительно лучше всего найти средство воспроизведения трассировки ввода / вывода.Иногда они скрываются под опциями отладчика.
Вот ссылка, в которой в 2008 году говорится о патчах для воспроизведения ввода / вывода в qemu.
http://wiki.qemu.org/Features/FaultTolerance - делаетВоспроизведение ввода / вывода для надежности / отказоустойчивости.
Эмуляция пространства пользователя QEMU может быть более воспроизводимой.Я не знаю, работает ли он в сочетании с MARSS
Кстати: вопрос воспроизводимости не только актуален для симуляторов.Это также имеет отношение к надежности и отладке.
Вы можете найти универсальное средство воспроизведения Linux, которое вы можете использовать, чтобы сделать вашу систему поверх QEMU / MARSS более воспроизводимой.
Внутри MARSS вы можете использовать возможности контрольной точки ptlcall, чтобы взять контрольную точку сразу после того момента, когда ваш тест (при условии, что вы используете SPEC или подобное) выполнил много начальных операций ввода-вывода, идо следующего ввода-вывода Многие тесты делают много начального ввода-вывода, затем некоторое время запускают в пользовательском коде, а затем делают какой-то окончательный ввод-вывод.Используя эти контрольные точки, вы можете избежать системных вызовов, меняющихся во времени.
Аналогично Симпоинты, http://www.marss86.org/~marss86/index.php/Simpoints
Кстати, мне только что напомнили о другом способе, которым программы могутбыть недетерминированным (кроме случайного зависи мости от времени или многопроцессорных взаимодействий): они могут явно и неотъемлемо зависеть от времени.
Например, версия langer98 Livmore Loops показывает, сколько времени занял цикл, и еслинедостаточно времени тратится, увеличивает счетчик циклов.Здесь вы можете записывать внешние взаимодействия, такие как время и системные вызовы, и программа может стать воспроизводимой, но вы не будете точно измерять, что она будет делать на вашем новом, более быстром, компьютере.
Обратное: представьте, что у вас есть переключатель оптимизации компилятора в форме «примените эту действительно дорогую оптимизацию не более чем на 2 часа, затем остановитесь ...»