DisAsm более менее работоспособен (по крайне мере на ошибки пока не налетал), так что да, чуть позже только
DisAsm более менее работоспособен (по крайне мере на ошибки пока не налетал), так что да, чуть позже только
Подчистил некоторое количество хвостов - в плане ошибок, неточностей и неудобств. Не все, но, скорее всего, на этом пока остановлюсь (если ошибок опять не найду).
Очень удобно, что стало возможным искать разное
Поиск сделан достаточно дубово. Берётся содержимое пятого столбца окна дизасма. Что туда попадёт - можно посмотреть, сделав Ctrl/C и вставив текст куда угодно, хоть в Notepad. Далее - табуляции заменяются на пробел, выкидываются переходы на новую строку, а последовательности пробелов заменяются на один. Получившаяся строка ищется от следующей ячейки (если поиск вперёд) или предыдущей (поиск назад) и до последней/первой ячейки, с содержимом которых повторяется та же операции и результат проверяется на наличии строки поиска как подстроки. То есть - если есть метки - можно искать метку, если есть комментарии - можно искать в комментариях, но по любой части команды (только принимая во внимание, что после запятой, разделяющей операнды - идёт пробел. Ну и любые комбинации. Если очередная ячейка найдена - становится текущей, если не найдена - текущая не меняется.
Никаких вариантов а ля * (любое количество любых символов) или ? (один любой символ). Если и буду делать - как-нибудь, если понадобится.
А вообще странно - чего я давно не сделал поиск
Как уже написал в топике про ImageUtils - устал от него и (подтолкнула текущая возня с дизасмом одной проги) продолжил доработку DisAsm-11. Про добавленный поиск уже написал, но на нём не остановился.
Когда-то достаточно давно в DisAsm-11 было добавлено определение макровызовов, которые, ко всему прочему, генерировались в зависимости от операционки для программы. Технически - всё работало, но было два Но. Одно Но было не очень так чтобы Но, скорее - но, но... Неудобно было. Это было Но - но вызвать с клавиатуры или интерфейса распознание макровызова было не возможно. Поэтому было встроен механизм - если идёт анализ кода (при загрузке или по кнопке C) - то идёт попытка и распознать макровызовы. Так что - не сильно не удобно, но.. не удобно
Второе Но, даже НО - добавление новых макровызовов в процесс определения было КРАЙНЕ НЕДОБНО сделано. Нужно было добавить объекты-описания на уровне исходников. То есть захотел ещё один макро - редактируй исходники. Но, по ряду причин, было сделано как сделано и в принципе - неплохо работало.
Занялся я дизасмом одной проги под RSX - а для RSX никаких описаний не было. Можно было пойти по старому, проверенному пути, но в голове начала-продолжила крутится мысль об изменения механизма и источника данных для определения макровызово. А в силу некоторых изменений внутри DisAsm-а - стало возможным изменить структуру описания шаблонов для поиска макровызовов и в результате - вынести их из DisAsm-а.
В общем, где-то примерно со среды началась доработка. Сегодня наконец стали появляться визуальные результаты
Как выглядит на текущий момент.
Загружаем в DisAsm программу
Обращаю внимание, что в левом окне текущая ячейка - начало последовательности макровызова, а в правом верхнем - блок, описывающий макровызов, на который ссылается последовательность из левого окна
Жмём Alt/M и...
Получаем макровызов в левом окне и подстановку-определение блока макровызова в правом верхнем
Из предыдущего механизма была взята визуализация макро-команды (но есть добавки), а подгрузка определений из файла и сопоставления содержимого ячеек памяти с шаблономи - это новое.
Вот тут мне RSX подкинула бяку
или даже так можноКод:QIO$ 2440, 15, 15, K00442, 0, <L21640, 2, 0, 0, 0, 0>
Но это ещё предстоит допилитьКод:QIO$ 2440, 15, 15, K00442, 0, <L21640, 2>
Как выглядит описание шаблонов на текущий момент:
Из автоматических плюсов - с блоками-описаниями макровызовов предыдущий подход работать не умел, здесь появился автоматом.Код:DIR$ ; source operand from instruction ; srcarg 012746 srcarg [MCallPointer] 000000:000001 104377 QIO$ srcArg1, srcArg2, srcArg3, srcArg4, srcArg5, srcIO1, srcIO2, srcIO3, srcIO4, srcIO5, srcIO6 [byte] 001 ; dic [byte] 014:377 ; dpb size 0:0 srcArg1 ; function 0:0 srcArg2 ; lun [byte] 0:0 srcArg3 ; efn [byte] 0:0 [DPointer] 0:0 srcArg4 ; iost pointer [CPointer] 0:0 srcArg5 ; ast pointer [DPointer] 0:0 srcIO1 0:0 srcIO2 0:0 srcIO3 0:0 srcIO4 0:0 srcIO5 0:0 srcIO6 QIOW$ srcArg1, srcArg2, srcArg3, srcArg4, srcArg5, srcIO1, srcIO2, srcIO3, srcIO4, srcIO5, srcIO6 [byte] 003 ; dic [byte] 014:377 ; dpb size 0:0 srcArg1 ; function 0:0 srcArg2 ; lun [byte] 0:0 srcArg3 ; efn [byte] 0:0 [DPointer] 0:0 srcArg4 ; iost pointer [CPointer] 0:0 srcArg5 ; ast pointer [DPointer] 0:0 srcIO1 0:0 srcIO2 0:0 srcIO3 0:0 srcIO4 0:0 srcIO5 0:0 srcIO6
Из неавтоматических плюсов - в шаблоне можно указать тип ссылки (скажем, для DIR$ - что она ссылается на блок-описания макроса - MCallPointer) - и для ячейки автоматом выставится нужный тип, что так же может привести к цепочке последствия - скажем, в случае того же DIR$ автоматом будет попытка определения макроса в блоке-описании, что и можно наблюдать на картинках.
Ещё изменения в работа с шаблонами - теперь можно описать несколько шаблонов - в зависимости от процессора, операционки, типа файла и т.п., а так же можно описать шаблон под дизасм конкретной программы - приведенный выше шаблон сейчас сделан как раз в таком сценарии. Причём, если исходник шаблона был изменён - при попытке обратится к Alt/M DisAsm-11 это увидет - и подгрузит новый вариант.
Что ещё в планах
Изменение принципа работы с шаблонами
Для шаблонов из каталога, где лежит DisAsm11.exe - в начале дизасм-а они будут подгружаться в сеанс и дальше их изменения на текущем дизасме отражаться не будут
Для шаблонов, связанных с дизассемблированной программы - изменения будут определяться, сгенерированные обращения для шаблонов, которые были удалены или изменены - будут аннулироваться, но после подгрузки новых - для ранее сгенерированных обращений будет повторяться поиск шаблона
Возможно (!! пока ешё не определился) будут добавлны также шаблоны уровня каталога - то есть если в каталоге лежит несколько дизассемблируемых программ - для них можно будет создать общие шаблоны. Но пока ценность такого не понятна.
Так же есть мысль добавить возможно переносить комментарии из шаблона в дизасм. Тут вроде всё должно быть не сильно сложно.
Практически наверняка будут ещё аттрибуты (типа MCallPointer) уровня шаблона и уровня заголовка-описания (там, где DIR$) шаблона - но они добавляются из практической необходимости, делать по сценарию - а давайте добавим ещё такой, такой и сякой аттрибут, просто что бы было - не буду
Так же теперь появляется возможность описывать не только макровызовы, но и определять всякие стандартные процедуры, скажем - те, которые в SYSLIB. Думаю. Механизм в целом будет похож на работы с макросыми, но есть (в визуализации) существенные отличия. Так что тут пока вообще никак
В целом же пока работы идут в режиме тестирования - буду накидывать другие макровызовы и смотреть визуализацию, в том числе - перенесу описания из предыдущего варианта, и - искать-исправлять ошибки плюс добавление функционала, что бы старые определения работали полностью
Последний раз редактировалось Hunta; 12.11.2024 в 15:21.
Из реализованного
Для QIOW$ - проверка алгоритма, а не реальная структура макро-вызова
Как выглядит шаблон:
Планы дальше - накидывать другие макровызовы и смотреть визуализацию, перенес описаний из предыдущего варианта, искать-исправлять ошибки плюс добавление функционала, что бы старые определения работали полностьюКод:QIO$ srcArg1, srcArg2, srcArg3, srcArg4, srcArg5, <srcIO1, srcIO2, srcIO3, srcIO4, srcIO5, srcIO6> [byte] 001 ; dic [byte] 014:377 ; dpb size 0:0 srcArg1 ; function 0:0 srcArg2 ; lun [byte] 0:0 srcArg3 ; efn [byte] 0:0 [DPointer] 0:0 srcArg4 ; iost pointer [CPointer] 0:0 srcArg5 ; ast pointer [DPointer] 0:0 srcIO1 0:0 srcIO2 0:0 srcIO3 0:0 srcIO4 0:0 srcIO5 0:0 srcIO6 QIOW$ srcArg1, srcArg2, srcArg3, <<srcArg4>>, <srcArg5>, <<srcIO1, srcIO2>, <srcIO3, srcIO4>, srcIO5, srcIO6> [byte] 003 ; dic [byte] 014:377 ; dpb size 0:0 srcArg1 ; function 0:0 srcArg2 ; lun [byte] 0:0 srcArg3 ; efn [byte] 0:0 [DPointer] 0:0 srcArg4 ; iost pointer [CPointer] 0:0 srcArg5 ; ast pointer [DPointer] 0:0 srcIO1 0:0 srcIO2 0:0 srcIO3 0:0 srcIO4 0:0 srcIO5 0:0 srcIO6
Ну, технически это не что-то новое, в старом варианте что-то (похожее) было, но в новом реализовано по другому.
Как это выглядит на картинке
И в шаблоне
Варианты для команд из макросов я добавил в самом начале этой доработки, но вот проверка на совпадение с шаблоном и подготовка данных для визуализациии - потребовали некоторого количества кода. Сама визуализация отработала сразуКод:MRKT$S srcEF, srcTM, srcTU, srcAST 01xx46 srcEF | 005046 01xx46 srcTM | 005046 01xx46 srcTU | 005046 01xx46 srcAST | 005046 012746 [byte] 27 ; dic [byte] 5 ; dpb size 104377
Развлечения продолжаются...
- - - Добавлено - - -
Глядя на картинку выше - так и хочется всё это дело описывать и мнемониками команд, но.. к такому подвигу пока не готов
Возможно(!) - для стандартных процедур и кусков кода сделаю что-то промежуточное - будет браться листинг и допиливаться под шаблон с сохранением какой-то информации, но... пока не думал на эту тему
Последний раз редактировалось Hunta; 13.11.2024 в 14:59.
Приведённой выше картинки и шаблону не верить - сразу две ошибки - в шаблонке и в обрабатывающем коде
Правильно должно быть так:
Код:N14576: MRKT$S #30, R0, #2
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Набросал несколько макросов, исправил несколько ошибок
- - - Добавлено - - -
В целом - я не знаю, сколько бы описывал эти три макроса при старом подходе.
При новом (если не считать посаженные ошибки) на шаблон макроса уходит меньше минуты
19 макросов. Копирую исходник из RSXMAC.SML, дальше беру как образец уже описанный макрос и подрихтую его под новый.
Основное время уходит на проверку результата, так как механизм ещё отлаживается и пока никаких сообщений - что не понравилось в шаблонах
- - - Добавлено - - -
В общем и целом - механизм достаточно отлажен и пока чего-то ещё кардинального добавлять вроде не требуется.
Так что попробую добавить отслеживание изменений шаблонов (тех, которые были использованы для генерации макровызово) и автоматическое сначала аннулирование, а затем повторный поиск.
Ну и продолжу добавлять новые шаблоны.
Последний раз редактировалось Hunta; 14.11.2024 в 10:09.
Немного в сторону - некоторые разборки с git - хочу всю ветку, сделанную для проверки нового подхода, перенести в master. Был бы один коммит - вообще не вопрос, а тут несколько и хочу все сохранить. Не сильно большой спец по git, поэтому займёт некоторое время
Оказалось, сделать просто - но из командной строки
Продолжил развлекаться с шаблонами и дальнейшей разработкой
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
