|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 19 May 2003 21:17:13
To : Oleg Drokin
Subject : Re: SuSE 8.2 sucks ???
--------------------------------------------------------------------------------
>>> Oleg Drokin wrote:
AB>> Вас смутили нопы ? Очень похоже на обычное выравнивение по границе слова
AB>> памяти. Это вообще ни о чем не говорит. Что внутри бинарников самого
OD> С каких пор у нас на x86 (на pentium обычном, заметим) 128ми битное слово?
С памятью он работает, кстати, вот такими вот словами.
OD> Выравнивание прямо перед вызовом функции? Hовое слово в оптимизации, надо
OD> думать. А перед этим, еще и двойной jump для большей оптимизации. И как ни
OD> странно ни gcc 3.3 релиз, ни gcc 3.2.3 ни gcc 2.95 к такой "оптимизации" не
OD> прибегают. Еще обратите внимание куда прыгает последний call ... Hу я
OD> конечно
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OD> знаю что некоторые продвинутые
OD> обфускаторы используют такую технику, но чтобы обычный gcc...
Вот очень похожий "кривой" пример из моего демонстрационного объектника:
(текст функции: `int f(void) { return g(); }' ) с тем отличием, что был
2.95.4, а не 3.2:
(objdump -d объектника)
00000010 <f>:
10: 55 push %ebp
11: 89 e5 mov %esp,%ebp
13: 83 ec 14 sub $0x14,%esp
16: 53 push %ebx
17: e8 00 00 00 00 call 1c <f+0xc>
1c: 5b pop %ebx
1d: 81 c3 03 00 00 00 add $0x3,%ebx
23: e8 fc ff ff ff call 24 <f+0x14>
28: 5b pop %ebx
29: 89 ec mov %ebp,%esp
2b: 5d pop %ebp
2c: c3 ret
Видим кучу левых действий и тот же мнимый переход на следующий байт
(смещение 23, hex).
А вот что из этого сделал линкер в готовой so'шке:
00000550 <f>:
550: 55 push %ebp
551: 89 e5 mov %esp,%ebp
553: 83 ec 14 sub $0x14,%esp
556: 53 push %ebx
557: e8 00 00 00 00 call 55c <f+0xc>
55c: 5b pop %ebx
55d: 81 c3 28 11 00 00 add $0x1128,%ebx
563: e8 d0 fe ff ff call 438 <_init+0x1c>
568: 5b pop %ebx
569: 89 ec mov %ebp,%esp
56b: 5d pop %ebp
56c: c3 ret
О чудо!!! - каким-то образом код стал нормальным, call стал
показывать на нормальное место... Hеожиданно, да-а?
А всё почему? А потому что -fPIC. Олег, Вы точно уверены, что никакой
PIC туда не затесался?
OD> Hу вот я счас еще и бинарники дистрибутива полезу разгребать ;) Мне хватает
OD> тех что оно мне накомпилило.
А вот загляните в бинарники. Хотя бы свои после линковки. Мне кажется, что
там все эти чудеса вдруг пропадут... Включая странные jmp'ы...
(Эх, видимо, нет у Вас background'а возни с объектными файлами. А то знали
бы, что в таких call'ах в поле смещения может стоять что угодно. Hапример,
смещение следующего такого call'а от начала секции...)
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
