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


Список сообщений | Написать новое | Ответить на сообщение | Домой Поиск:
Предыдущее сообщение | Следующее сообщение
From : Юрий Пронякин
To : valerius
Subj : А вот вопрос, однако...
> .Sym-файл ядра разорван на 2 части? Что-то я видел только одну, поставляемую с каждым ядром...

Да, до некоторого момента их было две, примерно одинакового размера (одна - os2krnl.sym, вторая - os2krnl.svm (тоже sym-файл, просто переименованный). Аргументировалось их наличие тем, что суммарный размер комбинированнного файла превышает возможности каких-то утилит, с этими файлами работающими. Потом почему-то Скотт начал в архив вкладывать только один файл, но размер его в два раза не вырос, остался практически таким же, как у тех половинок.

> А где взять вторую? Их можно объединить в один, написав скрипт для IDA?

Я сейчас глянул на содержимое тех половинок. В общем, хорошо, что остался только один файл. Потому что половинки содержали взаимно-противоречивую информацию.

>> Но на самом деле тебе от 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, только в бинарной форме.)
Кстати, обрати внимание, что многие адреса имеют по несколько имён. IDA такого не позволяет.

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

Да, текст на выходе дизассемблера примерно в десять раз больше исходного бинарника.

> Если первое, то неудивительно -- ядро -- это все-таки около 80 Мб исходников...

На самом деле - во много раз меньше. Но не в этом дело. Даже в 10 МБ откомментированных исходников разобраться - нужна уйма времени. А тут - никаких комментариев, только asm. Сколько лет ты его править будешь?

Забудь.

Mon 18 Jun 2007 15:28 Mozilla/5.0 (OS/2; U; Warp 4.5; ru-RU; rv:1.7.12) 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.