Re: [d-kernel] __stack_chk_fail

[Sergey Vlasov <vsu@altlinux.ru>]

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

On Mon, Oct 23, 2006 at 06:17:22PM +0300, Michael Shigorin wrote:
> On Mon, Oct 23, 2006 at 09:06:44AM +0300, Eugene Ostapets wrote:
> > > > Если с программами все понятно - линковать с помощью gcc,
> > > > то вот что делать с модулями ядра при появлении такого
> > > > undef? В гугле все только жалуются, решения найти не смог,
> > > > а kqemu хочется...
> > > -U_FORTIFY_SOURCE -fno-stack-protector
> > Тогда следующий вопрос, от человека, испорченого хорошим...
> > Я вообще не разбирался с техникой сборки 2.6.х, куда эти флаги
> > всандалить, чтобы заработало? :)
> 
> %remove_optflags?

Мимо.  Проблема не в том, что в %optflags добавлено что-то лишнее (на
самом деле ядро при сборке вообще не использует %optflags, все флаги
выставляются сборочной системой ядра по заданным опциям конфигурации и
возможностям компилятора).  Проблема в том, что gcc 4.1 теперь по
умолчанию включает опцию -fstack-protector, а ядро 2.6.16 к этому не
готово - автоматическое отключение -fstack-protector для совместимости с
подобными сборками gcc появилось только в 2.6.18, а поддержку
использования -fstack-protector в ядре добавили ещё позже.

После некоторой проверки я выложу патч, который добавляет в CFLAGS опцию
-fno-stack-protector, если компилятор её поддерживает - проблема исчезнет
после пересборки ядер, собиравшихся gcc 4.1, с этим патчем.

Кстати, в этой области есть ещё одни грабли - vDSO в ядре теперь тоже
собирается с прибитым гвоздями -Wl,--hash-style=gnu, что приводит к
несовместимости собранных таким образом ядер со старыми версиями glibc.
Это тоже было исправлено в 2.6.18.

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