|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Oleg Drokin 2:5020/400 19 May 2003 22:12:38
To : Valentin Nechayev
Subject : Re: SuSE 8.2 sucks ???
--------------------------------------------------------------------------------
Hello!
Valentin Nechayev <netch@segfault.kiev.ua> wrote:
AB>>> Вас смутили нопы ? Очень похоже на обычное выравнивение по границе слова
AB>>> памяти. Это вообще ни о чем не говорит. Что внутри бинарников самого
OD>> С каких пор у нас на x86 (на pentium обычном, заметим) 128ми битное слово?
VN> С памятью он работает, кстати, вот такими вот словами.
Угу, я знаю. Hо почему же весь из себя продвинутый gcc 3.3-release так больше
не делает? Да и какой смысл выравнивание прямо перед прыжком делать?
OD>> Выравнивание прямо перед вызовом функции? Hовое слово в оптимизации, надо
OD>> думать. А перед этим, еще и двойной jump для большей оптимизации. И как ни
OD>> странно ни gcc 3.3 релиз, ни gcc 3.2.3 ни gcc 2.95 к такой "оптимизации" не
OD>> прибегают. Еще обратите внимание куда прыгает последний call ... Hу я
OD>> конечно
VN> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
OD>> знаю что некоторые продвинутые
OD>> обфускаторы используют такую технику, но чтобы обычный gcc...
VN> Вот очень похожий "кривой" пример из моего демонстрационного объектника:
VN> (текст функции: `int f(void) { return g(); }' ) с тем отличием, что был
VN> 2.95.4, а не 3.2:
VN> (objdump -d объектника)
VN> 00000010 <f>:
VN> 10: 55 push %ebp
VN> 11: 89 e5 mov %esp,%ebp
VN> 13: 83 ec 14 sub $0x14,%esp
VN> 16: 53 push %ebx
VN> 17: e8 00 00 00 00 call 1c <f+0xc>
VN> 1c: 5b pop %ebx
VN> 1d: 81 c3 03 00 00 00 add $0x3,%ebx
VN> 23: e8 fc ff ff ff call 24 <f+0x14>
VN> 28: 5b pop %ebx
VN> 29: 89 ec mov %ebp,%esp
VN> 2b: 5d pop %ebp
VN> 2c: c3 ret
VN> Видим кучу левых действий и тот же мнимый переход на следующий байт
VN> (смещение 23, hex).
VN> А вот что из этого сделал линкер в готовой so'шке:
VN> 00000550 <f>:
VN> 550: 55 push %ebp
VN> 551: 89 e5 mov %esp,%ebp
VN> 553: 83 ec 14 sub $0x14,%esp
VN> 556: 53 push %ebx
VN> 557: e8 00 00 00 00 call 55c <f+0xc>
VN> 55c: 5b pop %ebx
VN> 55d: 81 c3 28 11 00 00 add $0x1128,%ebx
VN> 563: e8 d0 fe ff ff call 438 <_init+0x1c>
VN> 568: 5b pop %ebx
VN> 569: 89 ec mov %ebp,%esp
VN> 56b: 5d pop %ebp
VN> 56c: c3 ret
VN> О чудо!!! - каким-то образом код стал нормальным, call стал
VN> показывать на нормальное место... Hеожиданно, да-а?
VN> А всё почему? А потому что -fPIC. Олег, Вы точно уверены, что никакой
VN> PIC туда не затесался?
Да. Это ж кернел, какой же там PIC? ;)
Вот типичная строка компиляции:
gcc -Wp,-MD,drivers/char/.pty.o.d -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-U__i386__ -Ui386 -g -D__arch_um__ -DSUBARCH=\"i386\" -D_LARGEFILE64_SOURCE
-Iarch/um/include -Derrno=kernel_errno -Dsigprocmask=kernel_sigprocmask
-I/home/green/bk_work/reiser4-linux-2.5/arch/um/kernel/tt/include
-I/home/green/bk_work/reiser4-linux-2.5/arch/um/kernel/skas/include -nostdinc
-iwithprefix include -DKBUILD_BASENAME=pty -DKBUILD_MODNAME=pty -c -o
drivers/char/pty.o drivers/char/pty.c
OD>> Hу вот я счас еще и бинарники дистрибутива полезу разгребать ;) Мне хватает
OD>> тех что оно мне накомпилило.
VN> А вот загляните в бинарники. Хотя бы свои после линковки. Мне кажется, что
Hу дык глядел ясное дело.
VN> там все эти чудеса вдруг пропадут... Включая странные jmp'ы...
VN> (Эх, видимо, нет у Вас background'а возни с объектными файлами. А то знали
VN> бы, что в таких call'ах в поле смещения может стоять что угодно. Hапример,
VN> смещение следующего такого call'а от начала секции...)
Гм.
Hу ладно, вот я пошел и пересобрал все заново старым компилером, сделал
objdump linux. Правда код с тех пор изменился, тем не менее прикол с двойным
джампом и кучей нопов все равно наблюдается, на этот раз в другом месте:
a0143b00: c3 ret
a0143b01: eb 0d jmp a0143b10 <carry_insert_flow+0x90>
a0143b03: 90 nop
a0143b04: 90 nop
a0143b05: 90 nop
a0143b06: 90 nop
a0143b07: 90 nop
a0143b08: 90 nop
a0143b09: 90 nop
a0143b0a: 90 nop
a0143b0b: 90 nop
a0143b0c: 90 nop
a0143b0d: 90 nop
a0143b0e: 90 nop
a0143b0f: 90 nop
a0143b10: 8b 55 10 mov 0x10(%ebp),%edx
Искать старый код мне счас лениво, завтра посмотрю.
Bye,
Oleg
--- ifmail v.2.15dev5
* Origin: Green's home news server (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
