RU/2: Форум. Общение пользователей и разработчиков OS/2 (eCS). : А вот вопрос, однако...


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : valerius
To : Юрий Пронякин
Subj : А вот вопрос, однако...
> > .Sym-файл ядра разорван на 2 части? Что-то я видел только одну, поставляемую с каждым ядром...
>
> Да, до некоторого момента их было две, примерно одинакового размера (одна - os2krnl.sym, вторая - os2krnl.svm (тоже sym-файл, просто переименованный). Аргументировалось их наличие тем, что суммарный размер комбинированнного файла превышает возможности каких-то утилит, с этими файлами работающими. Потом почему-то Скотт начал в архив вкладывать только один файл, но размер его в два раза не вырос, остался практически таким же, как у тех половинок.
>
> > А где взять вторую? Их можно объединить в один, написав скрипт для IDA?
>
> Я сейчас глянул на содержимое тех половинок. В общем, хорошо, что остался только один файл. Потому что половинки содержали взаимно-противоречивую информацию.
>

Хм.. Как они могут быть противоречивыми? Может быть, они были для разных версий ядра? Например, одно для halfstrict ядра, другое для allstrict? -- Хотя, разные ядра, по идее, должны находиться в разных архивах...

> >> Но на самом деле тебе от sym-файла вообще толку мало: всё, что в нем для данной задачи есть полезного, и так содержится в заголовке LX-файла, а имена функций (которых в заголовке нет) для твоей затеи не интересны совершенно;
> >
> > Ну, имена могут подсказать хотя бы "смысловую нагрузку" каждой метки, а по смыслу все гораздо проще понять...
>
> Вот, появился этап "понять", хотя изначально речь шла о полностью автоматическом процессе. Если же заниматься ручной правкой, то это "удовольствие" на несколько лет. С сомнительным финалом.

Желательно, конечно, полностью автоматически, или полуавтоматически с небольшим обьемом ручной работы. Например, кое-что поручить скриптам, если это возможно...

> Что же до "смысловой нагрузки" - её там практически нет. Вот тебе кусочек содержимого os2krnl.sym (самое его начало):
> 0001:0000 DosGroupBase
> 0001:0000 SAS_base_area
> 0001:0020 SAS_dd_area
> 0001:0026 ABIOS_CDA_anchor_p
> 0001:0028 ABIOS_CDA_anchor_r
> 0001:002C SAS_vm_area
> 0001:005C SAS_task_area
> 0001:0078 SAS_file_area
> 0001:0084 SysInfoSeg
> 0001:0084 _SysInfoSeg
> 0001:0086 LocInfoSeg
> 0001:0086 _LocInfoSeg
> 0001:008A LocInfoSegRM
> 0001:008E CDIB_selector
> 0001:0280 SISData
> 0001:0280 _SISData
> 0001:0300 MSStack
> 0001:0700 _SAB
> 0001:0700 SAB
> 0001:0747 TSS
> 0001:0747 _tssTK
> 0001:07B0 Country_Code
> 0001:07B2 LeadByteTable
> 0001:07BA NullLeadByteTable
> 0001:07BC CharType
> 0001:08BC UNCfscList
> 0001:08E0 UNCfscLast
> 0001:08EC ksemMFT
> 0001:08EC _ksemMFT
> 0001:08F8 ksemVPB
> Много здесь информации? Ни что находится по именованному адресу, ни типов переменных, ни имён их полей, ничего, практически. (.map-файл видел? .sym - тот же .map, только в бинарной форме.)

Хм, типов и полей -- действительно нет. Но сами имена структур, функций, меток -- есть. Это хоть какая-то помощь. Но то что нету смещений полей, это конечно, очень плохо. Если есть конструкция типа

mov [var +_offset], _something

то var можно найти в .map- или .sym-файле (хотя в .sym'е и не все переменные, а только экспортированные...), а смысл _offset будет непонятен. Но если в программе поля структур не меняются при модификации, то смысл _offset и не нужен, достаточно просто числа, происхождение которого неизвестно (и неважно). А смещения полей в структурах и не требуется менять. Для Afterburner нужно лишь "разредить" некоторые инструкции NOP'ами, а также в выходном исполняемом файле (на выходе ассемблера) надо в спец. секцию вставить аннотации: метка начала (критической для виртуализации) инструкции, и метка конца padding'а из NOP'ов (насколько я понял из презентационного слайда про afterburner, который я смотрел). То есть, поля структур нам похоже, и не понадобятся... Что еще может такое потребоваться? Допустим, есть конструкция типа

mov eax, offset lalala

-- Тогда на выходе дизассемблера на месте offset lalala стоит какое-то число. Откуда оно взялось? Если вставлять NOP'ы между инструкциями, то смещения меток типа lalala могут меняться. А мы не знаем, что число в инструкции mov -- это смещение метки lalala, и что это смещение надо поправтить. Вот это может быть действительно проблемой... :(

> Кстати, обрати внимание, что многие адреса имеют по несколько имён. IDA такого не позволяет.
>

Ну, алиасы меток можно и убрать из map-файла, например, с помощью AWK-скрипта. Если есть .sym, то можно ли из .sym получить снова .map? (обратная операция делается при помощи утилиты mapsym).

> > > "Хозяйке на заметку": дизассемблированный файл обычно примерно в десять раз больше, чем исходный EXE. Сколько лет нужно потратить на причёсывание того, что получится из более чем мегабайтного файла ядра?
> >
> > В 10 раз больше что -- текст на выходе дизассемблера, или полученный его компиляцией бинарник?
>
> Да, текст на выходе дизассемблера примерно в десять раз больше исходного бинарника.
>
> > Если первое, то неудивительно -- ядро -- это все-таки около 80 Мб исходников...
>
> На самом деле - во много раз меньше. Но не в этом дело. Даже в 10 МБ откомментированных исходников разобраться - нужна уйма времени. А тут - никаких комментариев, только asm. Сколько лет ты его править будешь?
>
> Забудь.

:-/

Mon 18 Jun 2007 19:03 Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.10) Gecko/2005



Programmed by Dmitri Maximovich, Dmitry I. Platonoff, Eugen Kuleshov.
25.09.99 (c) 1999, RU/2. All rights reserved.
Rewritten by Dmitry Ban. All rights ignored.