Во-первых, о какой системе идёт речь? Для blackboxcomponentbuilder пошаговый отладчик уже есть. Не идеальный, но работать можно. Если A2OS, то я прямо готов участвовать в меру своих сил, при условии, что я буду не единственным участником. Опыт модификации отладчиков имеется, хотя все они были сделаны на высоком уровне, а не на уровне штатных интерфейсов отладки ОС. И в этом есть свои плюсы и минусы.
Во-вторых, с культом простоты совместимо только два варианта:
Цитата:
2) Реализовывать 2 режима, один release с оптимизациями, а второй debug без оптимизаций, как это сделано во многих системах.
4) Пошагово отлаживать оптимизированный код, допустим, сначала пошаговый отладчик будет на строчке 1, затем на строчке 3, затем на строчке 2 (так как инструкции из 2 и 3 были переставлены местами), затем перепрыгнет на 10 строчку (так как инструкции с 4 строки до 9 - это мертвый код). Думаю, будет очень необычно, зато близко к реальности.
Несколько уровней оптимизации на самом деле означают, что есть ЭН разных оптимизаций, которые включаются группами или каждая по отдельности. В худшем случае верификации подлежат 2^ЭН вариантов компилятора. Если мы лишаем себя возможности включать оптимизации независимо, то верификации подлежат только два варианта. Хотя может быть несколько целей оптимизации (как минимум, скорость, компактность и рилтаймовость), тогда будет более чем два варианта, но без комбинаторного взрыв хотя бы.
По поводу варианта 4, тут на самом деле надо ходить по ассемблерному коду. При хождении по оному нужно пытаться показать место в исходном коде. Иногда такого места не будет, иногда их получится более одного. Но если просто скакать по строчкам козликом, то
этот инструмент будет довольно безполезен. Именно ходить по шагам редко нужно, обычно нужно ставить точки прерывания. Поставить точку прерывания в произвольном месте оптимизированной программы нельзя. Тогда придётся искать ближайшее место, где можно поставить точку. Инструмент получается слишком сложным в использовании - за это опять же бог простоты низвергнет на нас свои молнии.
Вариант (5) запускать интерпретатор - это дешёвый вариант в худшем смысле слова. Кроме ошибок в прикладном коде, есть ещё и ошибки в компиляторе. Не остаётся никакого инструмента, чтобы отличить одно от другого. Запускать в режиме интерпретации всю систему может быть неприемлемо для производительности. Если запускать только часть, то требуется полная совместимость между компилируемым и интерпретируемым кодом - это усложнит проектирование и компилятора, и интерпретатора, а может быть, скажется и на конечном результате (возникнут ограничения на генерацию кода, например). Хотя этой дорогой я не ходил и точно не знаю. В лиспе совместимость между компилятором и интерпретатором есть, но в SBCL стек в отладчике показывается плохо, если там смешаны интерпретируемые и компилируемые кадры. Т.е. они не смогли дошлифовать качество.