LINUX.ORG.RU
Форум — Talks  

[ВНЕЗАПНО] Clang собирает Linux

 


0

1

В список рассылки cfe-dev пришло письмо с описанием успешного эксперимента по сборке ядра Linux с помощью компилятора Clang.

Специально для Ъ переведу часть письма (disclaimer: перевод неполный и местами достаточно вольный; правильнее даже назвать его пересказом):

Clang компилирует работающее ядро Linux (версия 2.6.36, SMP).

Общие детали

============

* Разработка и тестирование проводились на Macbook 5.1 (Intel C2D, x85_64) под управлением Debian GNU/Linux

* Ядро успешно загружается до runlevel 5 (X + сеть) на макбуке - как на настоящем железе, так и в qemu

* Ядро успешно загружается до runlevel 3 на второй тестовой машине, microATX desktop box (Intel Atom). Запустить X на этой машине мне пока что не удалось

* Ядро собирает само себя; в данный момент я работаю на «четвёртом поколении» самосборного Linux, собранного с помощью «четвёртого поколения» Clang

Основные успешно собранные подсистемы

=====================================

* Ключевые части ядра, файловые системы, шины, PCI, ACPI - не столкнулся ни с какими проблемами. Хотя стресс-тестирования не проводил.

* SMP, SMT, SysV, pthreadsm Posix IPC - тщательно протестированы и в основном работают нормально (есть некоторые проблемы с многозадачностью в user-mode).

* NUMA, swap, mm, аллокатор slab - с памятью всё хорошо, утечек по результатам тестирования не найдено

* Сеть (IPv4) - IPv4 работает нормально, за исключением IPSec. Netfilter и IPv6 независимо друг от друга вызывают зависания, однако есть идеи, как их можно пофиксить.

* Драйвера и firmware - в целом, ведут себя хорошо. Однако есть проблемы с драйверами, использующими криптографию (даже базовые процедуры ядра по вычислению crc). По крайней мере, удалось собрать и запустить (на макбуке) следующие драйвера:

** Графика и звук, вплоть до работающего под Flash видео

** Клавиатура. Не мигают светодиоды, но они и не нужны.

** DVD/CDROM

** Тычпад

** Всякие USB-штуки

** iSight

** Спикер

Менее важные подсистемы, которые не удалось собрать

===================================================

Возможно, какие-то из этих проблем были вызваны моими хаками в Clang, Linux или же конфигом ядра Linux. Что-то также мог забыть упомянуть.

* SELinux, Posix ACLs, IPSec, eCrypt и всё, что использует API для криптографии. В основном проблемы возникают из-за массивов переменной длины, которые используются в ряде структур - такое вот расширение GNU, не поддерживаемое другими компиляторами.

* IPv6 и Netfilter. Часть проблем с ними вызвана криптографией, а часть своя собственная.

* Виртуализация. Пока просто не собирается.

Проблемы, решаемые компиляцией с помощью GCC

============================================

* VDSO. При сборке с помощью Clang непонятным образом падает. При сборке с GCC работает.

* Boot. Код для первых шагов загрузки не собирается clang'ом (мешает инлайновый ассемблер, ещё одни расширения GNU). Проблема локализована, но пока что не ясно, как её решать.

Существенные проблемы

=====================

* Модули. Не загружаются. Примерно понятно, как это можно исправить, но работы придётся сделать довольно много.

В общем, автор полон энтузиазма и готов продолжать работать дальше. Он собирается поднять и поддерживать репозиторий, содержащий патчи, необходимые для сборки ядра clang'ом, и вообще хочет добиться production-уровня качества собираемого ядра. Ну и самому clang тоже достанутся плюшки патчи.

К обсуждению приглашаются эксперты, желающие высказать авторитетное мнение относительно данной истории успеха, личности автора/переводчика, нужности/ненужности Clang, GCC, Linux, FreeBSD, Apple, RMS, выпивки, женщин, блэкджека и далее по списку.

Источник

★

Главное что бы быстро и качественно работало, иначе какой смысл в велосипеде?

Xenius ★★★★★
()

Это же просто праздник какой-то на улице clang. Собирал бы он ещё и юзерспейс...

jcd ★★★★★
()

>Ядро собирает само себя
O_O
А по теме круто конечно, очень позитивная новость

proDOOMman ★★
()

>x85_64
Круто.

В основном проблемы возникают из-за массивов переменной длины, которые используются в ряде структур - такое вот расширение GNU, не поддерживаемое другими компиляторами.

Я что-то путаю, или это таки расширение стандарта С99, а не GNU?

В любом случае, пусть допилят С++ и соберут хотя бы Qt. Тогда посмотрим, нужен ли он.

unikoid ★★★
()
Ответ на: комментарий от unikoid

Возможно, что-то напутал я сам или же автор. В оригинале была игра слов: GNUtentions. Кстати, не исключено, что Clang просто ещё не поддерживает все расширения стандарта C99.

Zloddey ★
() автор топика
Ответ на: комментарий от Xenius

Автор пишет ещё и о работе над набором для стрессового/функционального/юнит-тестирования ведра. Хорошие тесты, как правило, помогают достижению критерия «быстро и качественно работает».

Zloddey ★
() автор топика

>Запустить X на этой машине мне пока что не удалось

вот это пока в минус , а так отличные новости ) хоть и для 64 бит,
для x86 из за registry pressure все будет не слишком радужно


Sylvia ★★★★★
()
Ответ на: комментарий от Zloddey

Погуглил, похоже стандарт с99 добавляет только локальные массивы переменной длины, а они же в качестве членов структур - таки расширение GNU.

unikoid ★★★
()

Ну и чо, быстрее-медленнее стало?

yoghurt ★★★★★
()
Ответ на: комментарий от unikoid

>> массивов переменной длины, которые используются в ряде структур

> Я что-то путаю, или это таки расширение стандарта С99, а не GNU?

по сцылке не ходил, но есть мнение (возможно, ошибочное):

в с99 есть такая фича: struct xxx { int a; int b[]; };

с такой структуры можно взять sizeof(): в данном случае, sizeof(struct xxx) == sizeof(int). т.е. последний элемент структуры прикидывается шлангом нулевой длины.

на эту структуру можно создать указатель.

всё. больше ничего толкового с ней сделать нельзя.

например, нельзя написать:

struct xxx t = { 10, { 1, 2, 3, 5 } };

или просто

struct xxx t = { 10 };

использовать можно только так:

struct xxx *p = malloc(sizeof(struct xxx) + sizeof(int) * n);
for (i = 0; i < n; ++i)
    p->b = i + 9;

вполне возможно, что гцц позволяет создавать и инициализировать «настоящие» экземпляры структур с «динамическими» массивами. если так, то это киллерфича, кстати, т.к. в будущем стандарте исо с1х такого пока нет :)

arsi ★★★★★
()
Ответ на: комментарий от arsi

>если так, то это киллерфича
Имхо, то, что поддерживается только одним компилятором не может быть киллерфичей, так как препятствует кроссплатформенности и стандартизации. А то получается как с MS, у которой своя реализация ODF, например, частично несовместимая с другими, зато «улучшенная». Да и с компиляторами у них тоже самое.

unikoid ★★★
()

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

tonn
()

FreeBSD не нужна. Ни в каком виде. Там обои скучные.

Enoch
()
Ответ на: комментарий от unikoid

> Имхо, то, что поддерживается только одним компилятором не может быть киллерфичей

если нечто реализовано в некотором компиляторе и зарекомендовало себя с хорошей стороны (растяжимо, да, понимаю), то это имеет шанс войти в стандарт. так было с гнутой инициализацией структур/объединений (по произвольным полям) и массивов (по произвольным индексам), которые вошли в с99. также в с99 вошло много функций с позикса. в с1х очень много «секюрных» функций с MSVC добавили. в исо сидят одни дармоеды (и мы же все об этом прекрасно знаем!!^^), которые от себя почти ничего не придумывают, только «легализируют» существующее.

arsi ★★★★★
()
Ответ на: комментарий от Zloddey

Zloddey> Есть дополнительные патчи, как на Linux, так и на Clang. По крайней мере, я так понял из письма

Ну тогда отбой - GCC можно не в режиме дедлайна разрабатывать.

Quasar ★★★★★
()
Ответ на: комментарий от devl547

# CC=clang CFLAGS="-O2" emerge -1 htop

Installing (1 of 1) sys-process/htop-0.8.3-r1

Auto-cleaning packages...



$htop --version
htop 0.8.3 - (C) 2004-2008 Hisham Muhammad.
Released under the GNU GPL.


$htop

все работает


$clang --version
clang version 2.8 (branches/release_28)
Target: i386-pc-linux-gnu
Thread model: posix

Sylvia ★★★★★
()

Внезапно: примитивный tcc с незапамятных времён «собирает Linux»!

Led ★★★☆☆
()
Ответ на: комментарий от true_admin

>а не факт что проблема в компилере :)

пересобрал из git - заработало. Таки в компилере.

devl547 ★★★★★
()
Ответ на: комментарий от n1

Linux, заметив всю эту возню вокруг компиляторов для Linux, решит что надо написать компилятор с нуля. и напишет :)

tommy ★★★★★
()
Ответ на: комментарий от devl547

возможно,
у меня релизный clang 2.8
с svn я пока не собираю, пусть несколько созреет )

Sylvia ★★★★★
()
Ответ на: комментарий от tommy

> Linux=Linus

Сенсация! Компиляторы возятся вокруг Линуса Торвальдса

rem Отсутствие редактирования сообщений, тем не менее, даёт пищу

Zloddey ★
() автор топика
Ответ на: комментарий от arsi

> в с99 есть такая фича: struct xxx { int a; int b[]; };

Если быть точным, то называется оно flexible array members

с такой структуры можно взять sizeof(): в данном случае, sizeof(struct xxx) == sizeof(int). т.е. последний элемент структуры прикидывается шлангом нулевой длины.

Тут ты не прав - в общем случае sizeof(struct xxx) != sizeof(int), так как компилятор может добавить padding перед массивом, чтобы int b[] оказался выровненным в естественных для него границах (конкретно в этом примере этого по очевидным причинам не произойдёт); собственно, для этого fam, как я понимаю, и предназначаются.

runtime ★★★★
()
Ответ на: комментарий от proud_anon

module-init-tools выкинуть не выйдет )
ну и libc достаточно полноценной не GPLной вроде нет для линукса,
если только взять бионик.... да, получится Android )

Sylvia ★★★★★
()
Ответ на: комментарий от Sylvia

>скучно?

да. clang и icc уже прикручены к генте.
tcc выброшен за ненадобностью.
open64 какой-то нерабочий, но судя по тестам очень нехило оптимизирует.

devl547 ★★★★★
()
Ответ на: комментарий от runtime

упс, действительно, о выравнивании забыл…

> собственно, для этого fam, как я понимаю, и предназначаются.

в с89 подобное давно использовалось в виде struct xxx { int a; int b[1]; }. но особо умные компиляторы потом сыпали варнингами о выходе за границы массива (при константной индексации). для этого, скорее всего, и ввели fam.

arsi ★★★★★
()
Ответ на: комментарий от devl547

> что еще интересного в мире x86 компиляторов?

suncc же!

arsi ★★★★★
()
Ответ на: комментарий от AptGet

Пациент скорее мертв, чем жив. Непонятно, зачем вообще откапывали.

GAMer ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Talks