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