[devel] DT_GNU_HASH

[devel] DT_GNU_HASH

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 537 bytes --]

В binutils более новой версии, чем у нас, реализована новая
опция --hash-style=gnu.  По утверждению редхатовцев, это дает
50% ускорение при запуске приложений.
http://sources.redhat.com/ml/binutils/2006-06/msg00418.html

В редхате перед выпуском FC6 решили пересобрать все пакеты с этой
опцией:
http://www.redhat.com/archives/fedora-announce-list/2006-July/msg00002.html

В общем накапливается уже несколько моментов, ради которых всё стоит
пересобрать: -D_FORTIFY_SOURCE, -fstack-protector, -pie, и вот теперь
--hash-style.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] DT_GNU_HASH

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 939 bytes --]

On Wed, Aug 09, 2006 at 04:07:26AM +0400, Alexey Tourbin wrote:
> В binutils более новой версии, чем у нас, реализована новая
> опция --hash-style=gnu.  По утверждению редхатовцев, это дает
> 50% ускорение при запуске приложений.
> http://sources.redhat.com/ml/binutils/2006-06/msg00418.html

Это даёт ~50% ускорение relocation'ов за счёт более подходящего алгоритма
хэширования.

> В редхате перед выпуском FC6 решили пересобрать все пакеты с этой
> опцией:
> http://www.redhat.com/archives/fedora-announce-list/2006-July/msg00002.html
> 
> В общем накапливается уже несколько моментов, ради которых всё стоит
> пересобрать: -D_FORTIFY_SOURCE, -fstack-protector, -pie, и вот теперь
> --hash-style.

Я не совсем понимаю, как автоматизировать -pie, но и без -pie причин для
пересборки достаточно.  Хуже другое: я не понимаю, как этот объём пакетов
выложить и как пользователи будут обновлять свои системы?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] DT_GNU_HASH

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 2411 bytes --]

On Wed, Aug 09, 2006 at 04:15:10AM +0400, Dmitry V. Levin wrote:
> On Wed, Aug 09, 2006 at 04:07:26AM +0400, Alexey Tourbin wrote:
> > В binutils более новой версии, чем у нас, реализована новая
> > опция --hash-style=gnu.  По утверждению редхатовцев, это дает
> > 50% ускорение при запуске приложений.
> > http://sources.redhat.com/ml/binutils/2006-06/msg00418.html
> 
> Это даёт ~50% ускорение relocation'ов за счёт более подходящего алгоритма
> хэширования.

И это должно заметно сказать на скорости работы shell скриптов,
в частности, на время загрузки системы.

Кстати, 50% ускорение -- это во сколько раз?  В два раза или в полтора?
Скорость увеличивается, а время загрузки уменьшается.  Следовало бы
говорить именно о времени загрузки.

> > В общем накапливается уже несколько моментов, ради которых всё стоит
> > пересобрать: -D_FORTIFY_SOURCE, -fstack-protector, -pie, и вот теперь
> > --hash-style.
> 
> Я не совсем понимаю, как автоматизировать -pie, но и без -pie причин для
> пересборки достаточно.  Хуже другое: я не понимаю, как этот объём пакетов
> выложить и как пользователи будут обновлять свои системы?

Помнится во времена подготовки M22 ко всем пакетам было требование:
пройти пересборку новым компилятором (gcc3.2).  Тогда ещё правда не было
ни регулярных пересборок, ни возможности автоматической пересборки; так
что это требование имело большое значение.

Теперь эти возможности есть, однако предлагаю поступить старым способом.
В час X, когда базовая сборочная среда будет готова, отрывается сезон
пересборки пакетов.  Maintainer'ам желательно найти какой-нибудь не
слишком пустяковый повод для пересборки пакетов.  Например, разобраться
c x86_64, или исправить что-нибудь из багзиллы.  В час Y сезон плавно
закрывается и наступает более глубокий фриз.  Думаю, что значительная
часть пакетов, и в особенности все важные пакеты, в промежуток X-Y будут
пересобраны.  Стоит ли тогда автоматически пересобрать оставшиеся
пакеты, я не знаю.

-pie действительно непросто автоматически прошить.  Но можно
воспользоваться вот какими соображениями.

1) если при компиляции объектных файлов не указана опция -fpic/-fPIC,
тогда автоматически врубать -fpie, если только не указана опция -fno-pie.

2) если при линковке не указана опция -shared, то автоматически врубать
опцию -pie, если только не указана -no-pie (кстати, кажется такой опции
нет).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] DT_GNU_HASH

[Денис Смирнов]

On Wed, Aug 09, 2006 at 04:15:10AM +0400, Dmitry V. Levin wrote:

DVL> Я не совсем понимаю, как автоматизировать -pie, но и без -pie причин для
DVL> пересборки достаточно.  Хуже другое: я не понимаю, как этот объём пакетов
DVL> выложить и как пользователи будут обновлять свои системы?

Общий объем пакетов для архитектуры i686 у нас 4.8G. Делать такое одним
проходом думаю слишком много вреда будет.

Я бы предложил сначала действительно обновить binutils, и, после того как
ты придумаешь как автоматизировать -pie, оставить месяц на плавную
пересборку пакетов. Пакеты, не собиравшиеся в этот период, уже можно потом
пересобрать группой, а можно и не пересобирать -- когда будем форкать
бранч, вот его содержимое целиком и пересобрать.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Хочешь стать бесконечно значительным, раздели себя на ноль.

Re: [devel] DT_GNU_HASH

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

On Wed, Aug 09, 2006 at 02:49:17PM +0400, Денис Смирнов wrote:
> On Wed, Aug 09, 2006 at 04:15:10AM +0400, Dmitry V. Levin wrote:
> 
> DVL> Я не совсем понимаю, как автоматизировать -pie, но и без -pie причин для
> DVL> пересборки достаточно.  Хуже другое: я не понимаю, как этот объём пакетов
> DVL> выложить и как пользователи будут обновлять свои системы?
> 
> Общий объем пакетов для архитектуры i686 у нас 4.8G. Делать такое одним
> проходом думаю слишком много вреда будет.
> 
> Я бы предложил сначала действительно обновить binutils,

К сожалению, для перехода на DT_GNU_HASH этого недостаточно, ещё нужно
обновить glibc, а это гораздо сложнее и дольше.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] DT_GNU_HASH

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

On Wed, Aug 09, 2006 at 04:58:45AM +0400, Alexey Tourbin wrote:
[...]
> Теперь эти возможности есть, однако предлагаю поступить старым способом.
> В час X, когда базовая сборочная среда будет готова, отрывается сезон
> пересборки пакетов.  Maintainer'ам желательно найти какой-нибудь не
> слишком пустяковый повод для пересборки пакетов.  Например, разобраться
> c x86_64, или исправить что-нибудь из багзиллы.  В час Y сезон плавно
> закрывается и наступает более глубокий фриз.  Думаю, что значительная
> часть пакетов, и в особенности все важные пакеты, в промежуток X-Y будут
> пересобраны.  Стоит ли тогда автоматически пересобрать оставшиеся
> пакеты, я не знаю.

Думаю что стоит.

> -pie действительно непросто автоматически прошить.  Но можно
> воспользоваться вот какими соображениями.
> 
> 1) если при компиляции объектных файлов не указана опция -fpic/-fPIC,
> тогда автоматически врубать -fpie, если только не указана опция -fno-pie.
> 
> 2) если при линковке не указана опция -shared, то автоматически врубать
> опцию -pie, если только не указана -no-pie (кстати, кажется такой опции
> нет).

Выглядит логично.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] DT_GNU_HASH

[Денис Смирнов]

On Wed, Aug 09, 2006 at 04:34:21PM +0400, Dmitry V. Levin wrote:

>> 1) если при компиляции объектных файлов не указана опция -fpic/-fPIC,
>> тогда автоматически врубать -fpie, если только не указана опция -fno-pie.
DVL> Выглядит логично.

Кстати, я правильно понимаю что -fpie несовместима с -fpic потому как ее
obsolete? То есть имеет смысл заменять -fpic на -fpie, там где это не
приносит проблем?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
> ... но на самом деле хочется БАСОВ =)))
Тогда нужны КОЛОНКИ :))
		-- mike in community@

Re: [devel] DT_GNU_HASH

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 567 bytes --]

On Wed, Aug 09, 2006 at 05:20:49PM +0400, Денис Смирнов wrote:
> On Wed, Aug 09, 2006 at 04:34:21PM +0400, Dmitry V. Levin wrote:
> 
> >> 1) если при компиляции объектных файлов не указана опция -fpic/-fPIC,
> >> тогда автоматически врубать -fpie, если только не указана опция -fno-pie.
> DVL> Выглядит логично.
> 
> Кстати, я правильно понимаю что -fpie несовместима с -fpic потому как ее
> obsolete? То есть имеет смысл заменять -fpic на -fpie, там где это не
> приносит проблем?

Нет.  Внимательно прочитайте описание -fpie в "info gcc".


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] I: gcc4.1-4.1.1-alt8, glibc-2.5-alt1

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]

On Wed, Aug 09, 2006 at 04:32:38PM +0400, Dmitry V. Levin wrote:
> On Wed, Aug 09, 2006 at 02:49:17PM +0400, Денис Смирнов wrote:
> > On Wed, Aug 09, 2006 at 04:15:10AM +0400, Dmitry V. Levin wrote:
> > 
> > DVL> Я не совсем понимаю, как автоматизировать -pie, но и без -pie причин для
> > DVL> пересборки достаточно.  Хуже другое: я не понимаю, как этот объём пакетов
> > DVL> выложить и как пользователи будут обновлять свои системы?
> > 
> > Общий объем пакетов для архитектуры i686 у нас 4.8G. Делать такое одним
> > проходом думаю слишком много вреда будет.
> > 
> > Я бы предложил сначала действительно обновить binutils,
> 
> К сожалению, для перехода на DT_GNU_HASH этого недостаточно, ещё нужно
> обновить glibc, а это гораздо сложнее и дольше.

gcc4.1-4.1.1-alt8 с включённым по умолчанию --hash-style=gnu вместе с
glibc-2.5-alt1 отправится сегодня в Сизиф по окончании тестовой пересборки
Сизифа.

Что касается параметров сборки по умолчанию, то, между прочим, в FC6 по
умолчанию включили вот что:
$ rpmquery -p --qf '%{OPTFLAGS}\n' libutempter-1.1.4-3.fc6.i386.rpm 
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables

Я думаю, что нам имеет смысл включить как -Wp,-D_FORTIFY_SOURCE=2
так и -fstack-protector по умолчанию прямо в gcc по аналогии с
--hash-style=gnu.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: gcc4.1-4.1.1-alt8, glibc-2.5-alt1

[Damir Shayhutdinov]

> Я думаю, что нам имеет смысл включить как -Wp,-D_FORTIFY_SOURCE=2
> так и -fstack-protector по умолчанию прямо в gcc по аналогии с
> --hash-style=gnu.
Поддерживаю. А -pie и -fpie отменяются в этом релизе Сизифа?

Re: [devel] I: gcc4.1-4.1.1-alt8, glibc-2.5-alt1

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 365 bytes --]

On Tue, Oct 03, 2006 at 04:30:03PM +0400, Damir Shayhutdinov wrote:
> > Я думаю, что нам имеет смысл включить как -Wp,-D_FORTIFY_SOURCE=2
> > так и -fstack-protector по умолчанию прямо в gcc по аналогии с
> > --hash-style=gnu.
> Поддерживаю. А -pie и -fpie отменяются в этом релизе Сизифа?

По умолчанию нет, я такой нагрузки сейчас не вытяну.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: gcc4.1-4.1.1-alt8, glibc-2.5-alt1

[Денис Смирнов]

On Tue, Oct 03, 2006 at 03:59:54PM +0400, Dmitry V. Levin wrote:

DVL> gcc4.1-4.1.1-alt8 с включённым по умолчанию --hash-style=gnu вместе с
DVL> glibc-2.5-alt1 отправится сегодня в Сизиф по окончании тестовой пересборки
DVL> Сизифа.

Glibc будет собрана с NTPL?

DVL> Я думаю, что нам имеет смысл включить как -Wp,-D_FORTIFY_SOURCE=2
DVL> так и -fstack-protector по умолчанию прямо в gcc по аналогии с
DVL> --hash-style=gnu.

Моему счастью не будет предела.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
бишь пофиксено методом выноса объекта фикса
		-- mike in #4618

Re: [devel] I: gcc4.1-4.1.1-alt8, glibc-2.5-alt1

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

On Tue, Oct 03, 2006 at 06:38:30PM +0400, Денис Смирнов wrote:
> On Tue, Oct 03, 2006 at 03:59:54PM +0400, Dmitry V. Levin wrote:
> 
> DVL> gcc4.1-4.1.1-alt8 с включённым по умолчанию --hash-style=gnu вместе с
> DVL> glibc-2.5-alt1 отправится сегодня в Сизиф по окончании тестовой пересборки
> DVL> Сизифа.
> 
> Glibc будет собрана с NTPL?

linuxthreads вынесена из glibc cvs в ports начиная с glibc-2.4,
какой смысл собирать неподдерживаемую библиотеку?

> DVL> Я думаю, что нам имеет смысл включить как -Wp,-D_FORTIFY_SOURCE=2
> DVL> так и -fstack-protector по умолчанию прямо в gcc по аналогии с
> DVL> --hash-style=gnu.
> 
> Моему счастью не будет предела.

:)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: gcc4.1-4.1.1-alt8, glibc-2.5-alt1

[Денис Смирнов]

On Tue, Oct 03, 2006 at 10:34:11PM +0400, Dmitry V. Levin wrote:

>> Glibc будет собрана с NTPL?
DVL> linuxthreads вынесена из glibc cvs в ports начиная с glibc-2.4,
DVL> какой смысл собирать неподдерживаемую библиотеку?

/me счастлив.
Спасибо.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Не надо совмещать простую задачу со сложной.
		-- ldv in devel@

Re: [devel] I: gcc4.1-4.1.1-alt8, glibc-2.5-alt1

[Serge Ryabchun]

On Tue, Oct 03, 2006 at 03:59:54PM +0400, Dmitry V. Levin wrote:
> Что касается параметров сборки по умолчанию, то, между прочим, в FC6 по
> умолчанию включили вот что:
> $ rpmquery -p --qf '%{OPTFLAGS}\n' libutempter-1.1.4-3.fc6.i386.rpm 
> -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
> -fasynchronous-unwind-tables
> 
> Я думаю, что нам имеет смысл включить как -Wp,-D_FORTIFY_SOURCE=2
> так и -fstack-protector по умолчанию прямо в gcc по аналогии с
> --hash-style=gnu.

Им же потом не только libutempter собирать. Может и ядро придется,
все же может не нужно, а? Выставлять FORTIFY_SOURCE в 0 и сбрасывать
fstack_protector вечно будет забываться в самый неподходящий момент.

Re: [devel] I: gcc4.1-4.1.1-alt8, glibc-2.5-alt1

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

On Wed, Oct 04, 2006 at 12:46:19AM +0300, Serge Ryabchun wrote:
> On Tue, Oct 03, 2006 at 03:59:54PM +0400, Dmitry V. Levin wrote:
> > Что касается параметров сборки по умолчанию, то, между прочим, в FC6 по
> > умолчанию включили вот что:
> > $ rpmquery -p --qf '%{OPTFLAGS}\n' libutempter-1.1.4-3.fc6.i386.rpm 
> > -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> > --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
> > -fasynchronous-unwind-tables
> > 
> > Я думаю, что нам имеет смысл включить как -Wp,-D_FORTIFY_SOURCE=2
> > так и -fstack-protector по умолчанию прямо в gcc по аналогии с
> > --hash-style=gnu.
> 
> Им же потом не только libutempter собирать.

Я, кстати, не в курсе, у них %optflags при сборке всех пакетов одинаковые
или нет?

> Может и ядро придется,

Да, для kernel это (пока и к большому сожалению) противопоказано.
Но это все заинтересованные и так знают, думаю что они уже сейчас могут
написать -Wp,-U_FORTIFY_SOURCE -fno-stack-protector.

> все же может не нужно, а? Выставлять FORTIFY_SOURCE в 0 и сбрасывать
> fstack_protector вечно будет забываться в самый неподходящий момент.

Я полагаю, что если даже в FC это сделали по умолчанию (в %optflags, не в
gcc, но это не принципиально), то мы тоже должны быть способны с этим
справиться.  На всякий случай я попробую посмотреть, какие пакеты в FC6
выключают _FORTIFY_SOURCE и stack-protector.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] I: gcc4.1-4.1.1-alt8, glibc-2.5-alt1

[Ildar Mulyukov]

On 03.10.2006 20:38:30, Денис Смирнов wrote:
> On Tue, Oct 03, 2006 at 03:59:54PM +0400, Dmitry V. Levin wrote:
> 
> DVL> gcc4.1-4.1.1-alt8 с включённым по умолчанию --hash-style=gnu
> вместе с
> DVL> glibc-2.5-alt1 отправится сегодня в Сизиф по окончании тестовой
> пересборки
> DVL> Сизифа.
> 
> Glibc будет собрана с NTPL?
Скорее всего, Вас нужна не NTPL, а TLS.

С уважением, Ильдар
--
Ildar  Mulyukov,
   free SW designer/programmer/packager
=========================================
email: ildar@altlinux.ru
ALT Linux Sisyphus http://www.sisyphus.ru
=========================================

Re: [devel] I: gcc4.1-4.1.1-alt8, glibc-2.5-alt1

[Денис Смирнов]

On Wed, Oct 04, 2006 at 12:49:59PM +0600, Ildar Mulyukov wrote:

>> Glibc будет собрана с NTPL?
IM> Скорее всего, Вас нужна не NTPL, а TLS.

AFAIR TLS у нас есть. А NPTL мне таки нужна. Для Asterisk, который на
каждое соединение тред создает, да и вообще на каждый чих тред создает.
При этом тестируется исключительно с NPTL.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Секретарши выбирают tuxracer :-) (да и админы им подъём 3D обычно тестируют)
		-- mike in devel@

Re: [devel] I: gcc4.1-4.1.1-alt8, glibc-2.5-alt1

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]

On Wed, Oct 04, 2006 at 01:55:22AM +0400, Dmitry V. Levin wrote:
> On Wed, Oct 04, 2006 at 12:46:19AM +0300, Serge Ryabchun wrote:
[...]
> > все же может не нужно, а? Выставлять FORTIFY_SOURCE в 0 и сбрасывать
> > fstack_protector вечно будет забываться в самый неподходящий момент.
> 
> Я полагаю, что если даже в FC это сделали по умолчанию (в %optflags, не в
> gcc, но это не принципиально), то мы тоже должны быть способны с этим
> справиться.  На всякий случай я попробую посмотреть, какие пакеты в FC6
> выключают _FORTIFY_SOURCE и stack-protector.

Выключающих _FORTIFY_SOURCE среди патчей почти не нашёл
(compat-gcc-*, frysk, gdb не в счёт),
зато нашёл исправляющие, например, dosfstools-2.11-fortify.patch

Со stack-protector'ом примерно такая же ситуация:
compat-gcc-*,
emacs (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174730),
linuxwacom,
valgrind-callgrind.

См. тж. http://google.com/codesearch?q=%22-fno-stack-protector%22


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]