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

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

Тема:

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

__, _,_ _, __, ___, \|_) \| \| \| \|_ ` / \| \ \| \| \| , \| / ~ ~ `~' ~~~ ~~~ ~~~