|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 19 May 2003 22:29:24
To : Oleg Drokin
Subject : Re: SuSE 8.2 sucks ???
--------------------------------------------------------------------------------
>>> Oleg Drokin wrote:
AB>>>> Вас смутили нопы ? Очень похоже на обычное выравнивение по границе слова
AB>>>> памяти. Это вообще ни о чем не говорит. Что внутри бинарников самого
OD>>> С каких пор у нас на x86 (на pentium обычном, заметим) 128ми битное слово?
VN>> С памятью он работает, кстати, вот такими вот словами.
OD> Угу, я знаю. Hо почему же весь из себя продвинутый gcc 3.3-release так
OD> больше не делает? Да и какой смысл выравнивание прямо перед прыжком делать?
А как работал -mpreferred-stack-boundary в 2.95 видели? Такая же глупость.
В этот раз они, видимо, решили помочь кэшу процессора разложить команды
на адекватных местах. Потом отказались.
Я сейчас быстрым просмотром objdump -d /5/bin/sh нашёл такие же шуточки
в GCC 3.2.2 от FreeBSD 5.1:
804864c: 83 38 00 cmpl $0x0,(%eax)
804864f: 74 34 je 0x8048685
8048651: eb 0d jmp 0x8048660
8048653: 90 nop
[...]
804865f: 90 nop
8048660: a1 cc 00 10 08 mov 0x81000cc,%eax
8048665: 8b 00 mov (%eax),%eax
А вот и документация к этому в info gcc - надо только было знать, что искать,
после того, как увидел глазами код:
`-malign-jumps=NUM'
Align instructions that are only jumped to to a 2 raised to a NUM
byte boundary. If `-malign-jumps' is not specified, the default is
2 if optimizing for a 386, and 4 if optimizing for a 486 unless
gas 2.8 (or later) is being used in which case the default is to
align the instruction on a 16 byte boundary if it is less than 8
bytes away.
Hу я бы не сказал, что тут было "less than 8 bytes away" - явно больше -
но копать надо именно тут. Что-то глючило, вероятно.
Да, это всё должно сопровождаться адекватным -malign-functions, иначе оно
хрен знает какие прыжки накомпилит...
OD>>> Выравнивание прямо перед вызовом функции? Hовое слово в оптимизации, надо
OD>>> думать. А перед этим, еще и двойной jump для большей оптимизации. И как ни
OD>>> странно ни gcc 3.3 релиз, ни gcc 3.2.3 ни gcc 2.95 к такой
OD>>> "оптимизации" не прибегают. Еще обратите внимание куда прыгает последний
OD>>> call ... Hу я конечно
VN>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VN>> А всё почему? А потому что -fPIC. Олег, Вы точно уверены, что никакой
VN>> PIC туда не затесался?
Я прогнал. PIC тут ни при чём, такое записано и для не-PIC версии.
Hу вот так вот оно хранит объектники - в поле такого смещения всегда
fc ff ff ff (-4 то есть), пока не сделает окончательный бинарник или so.
VN>> А вот загляните в бинарники. Хотя бы свои после линковки. Мне кажется, что
OD> Hу дык глядел ясное дело.
И что - продолжало делать call .+1? В nop'ы - верю, в это - не верю.
OD> Гм.
OD> Hу ладно, вот я пошел и пересобрал все заново старым компилером, сделал
OD> objdump linux. Правда код с тех пор изменился, тем не менее прикол с двойным
OD> джампом и кучей нопов все равно наблюдается, на этот раз в другом месте:
Про кучу нопов я тогда ничего не говорил, только предполагал ;)
Добавьте -malign-jumps=2 -malign-functions=2 и сравните результат.
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
