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

Имя:
e-mail:
FIDO:
Home page:
сохранить данные о вас

Тема:

> > > .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. Сколько лет ты его править будешь?
> > 
> > Забудь.
> 
> :-/

_, _, _, _, _ _ _,_ (_ \| / \ \|\ \| \| \|_/ , ) \| , \ / \| \\| \| \| \ ~ ~~~ ~ ~ ~ ~ ~ ~