LINUX.ORG.RU

Статус готовности CLang к сборке ядра Linux

 , , license bsd, lll, , , ,


0

1

В прошлом октябре был анонсирован проект по адаптации LLVM компилятора CLang к сборке ядра Linux. С тех пор прошло более полугода, и на днях разработчики опубликовали свой отчет о проделанной работе.

В целом:

  • Удалось получить работающую сборку ядер 2.6.37 и 2.6.38 (для некоторых конфигураций)
  • KVM и Xen использовать нельзя, причем последний пока даже не компилируется
  • Компилируются примерно 90% драйверов ядра, многие работают
  • Некоторые поставляемые сторонними вендорами драйвера (Broadcom, NVIDIA) работают отлично
  • Можно использовать многопроцессорные конфигурации (правда, только на x86), однако в некоторых случаях они требуют дополнительных усилий по доработке компилируемого кода

Что не работает:

  • Ассемблер для генерации кода реального режима (директивы code16gcc), поэтому, невозможно откомпилировать код начальной загрузки (для этой цели используется gas)
  • GCC-расширения языка C (некоторые работают, некоторые нет)
  • Опции генерации и оптимизации кода: -mregparm, -fcall-saved-reg, __arch_hweight*(), -pg, атрибут no_instrument_function, -fno-optimize-sibling-calls

Несмотря на возникающие трудности, разработчики полны энтузиазма. Свой проект они назвали LLL project, что расшифровывается как LLVM Linux project.

>>> Подробности

★★★★★

Проверено: mono ()
Последнее исправление: mono (всего исправлений: 2)

Ответ на: комментарий от anonymous

> Clang намного меньше

Когда он будет поддерживать столько же архитектур, сколько и gcc, тогда посмотрим на его размер.

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

> Когда он будет поддерживать столько же архитектур, сколько и gcc

на данный момент он умеет:

X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore

aho
()
Ответ на: комментарий от Lighting

> Почему ни один фанатик до сих пор не сказал, что же за мифически плюшки оно имеет?

Откуда столько дебилов, не умеющих читать?

У gcc множество архитектурных недостатков:

- Слишком много промежуточных представлений. В llvm же только один уровень.

- Отсутствие единообразного метода для написания преобразований

- Не разделяется код между языковыми frontend-ами

- Много древнего кода, который уже давно никто не понимает

- Написано на Си, с множеством костылей

- Платформозависимые части размазаны по всем уровням

В clang и llvm все эти недостатки отсутствуют. Очень четкое разделение по уровням абстракции. Легко добавляются произвольные преобразования между этими уровнями. Как результат - есть довольно мощный и легкоуправляемый статистический анализатор кода. Есть полноценная, работающая link time optimization (то убожество, что есть в gcc, еще лет 5 допиливать до рабочего состояния будут). Clang и llvm очень маленькие и понятные, один разработчик легко может добавить новую функциональность, не тратя годы на разборки с нагромождениями древнего хлама.

А вы, придурки, все про лицензии бухтите. Не важно это. Важны только технические характеристики.

anonymous
()
Ответ на: комментарий от skarrok

Поддержка для новой архитектуры добавляется элементарно, и занимает очень мало места. Посмотри на код.

anonymous
()
Ответ на: комментарий от mono

>Открой свою ссылку и узри, что поддержка C99 в GCC неполная.

Ты говоришь так, как будто есть несферический компилятор с полной поддержкой стандартов C/C++

gnu-eabi
()
Ответ на: комментарий от madcore

> Зачем нужен clang?

И про главную плюшку забыл: возможность использования компонентов компилятора внешними приложениями. Например, IDE. В XCode очень неплохой code completion сделан на основе clang, к VIM его тоже прикрутили уже. С gcc это нереально, он слишком монолитный.

anonymous
()

В треде одни сплошные Ъ (включая mono, подтвердившего новость) и никто не заметил, что ссылка ведет не туда. :D

Relan ★★★★★
()
Ответ на: комментарий от gnu-eabi

не знаю про все стандарты, но в сановском компиляторе поддержка С99 полная.

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

> Вот интересно, они адаптируют clang до совместимости с GCC-костылями или пишут патчи для ядра, чтобы лучше соответствовало стандартам?

The LLL folks «prefer adding things to Clang rather than patching the kernel», Lelbach said.

Рекомендую всё-таки сходить по ссылке и почитать, там довольно интересно.

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

Смотри внимательнее.. инфа с которой написана новость там в самом конце статьи. Если так важно, сейчас добавлю прямую ссылку на LLL.

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

Не всегда. например на такой код:

bind1st(mem_fun(&A::check), a);

где A::check принимает ссылку, оба компилятора выдают сообщения далекие от истинной причины ошибки.

elverion
()
Ответ на: комментарий от mono

> Смотри внимательнее.. инфа с которой написана новость там в самом конце статьи. Если так важно, сейчас добавлю прямую ссылку на LLL.

Вижу-вижу. Так я её, собственно, и нашёл. :) Зачем давать ссылку на кучу всего не по теме новости? Лучше сразу на http://lwn.net/Articles/441018/

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

Не нужен ты, тупорылый ламер.

В gcc много проходов, и только в одном из них (GIMPLE-SSA) используется SSA. В LLVM он везде, в том числе и при кодогенерации и register allocation.

anonymous
()
Ответ на: комментарий от pylin

BSD и PCC компилируется. У них есть такое правило, что использовать только ANSI C. Это единственное что мне нравится в стане BSD.

anonymous
()
Ответ на: комментарий от th3m3

> Ну и нафига это чудо? Ненужно.

Вы не только не утруждаете себя чтением по указанной ссылке, но и не читаете комментарии выше. Какой смысл в вашем вопросе, если вы все равно не прочтете ответ?

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

Ну если ты связи не видишь, то ты просто запредельно тупой и недоразвитый. Задумайся об этом.

anonymous
()
Ответ на: комментарий от aho

>> Когда он будет поддерживать столько же архитектур, сколько и gcc

на данный момент он умеет:


X86, X86-64, PowerPC, PowerPC-64, ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ, and XCore


а также кодогенерацию в С через
llc -march=c program.bc -o program.c
сс program.c -lstdc++
http://www.llvm.org/docs/FAQ.html#translatecxx

вопрос, ну и чем оно отличается от того же Comeau C++ зhttp://en.wikipedia.org/wiki/Comeau_C++ а $50 ,http://www.comeaucomputing.com/faqs/genfaq.html#howmuch , который давно умеет конпелировать через кодогенерацию в plain С?

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

> опрос, ну и чем оно отличается от того же Comeau C++ зhttp://en.wikipedia.org/wiki/Comeau_C++ а $50 ,http://www.comeaucomputing.com/faqs/genfaq.html#howmuch , который давно умеет конпелировать через кодогенерацию в plain С?

Тем, дурик, что умеет кодогенерацию не только через plain C.

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

> BSD и PCC компилируется. У них есть такое правило, что использовать только ANSI C.

кстати, как дела с конкурсом? http://bsdfund.org/bundle/

Ядро Linux ещё PCC не собирается из коробки, попробовал вот и обломался на п gсс-измы. Радует, что у Clanga ситуация в целом получше, может что-то и для dev-lang/pcc тоже пригодится.

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

export в template? а что ещё оно умеет по сравнению с llc -march=c ?

anonymous
()

А вообще, единственное хорошее, что выйдет из этого проекта - поддержка полезных gcc-измов в Clang :)

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

я вообще про то, что если кому-то сильно не хватает какой-то архитектуры среди поддерживаемых LLVM — то он прям вот сейчас может брать C backend и допиливать его напильником, при этом придётся пересобрать все С++ библиотеки из-за несовместимостей ABI C backend-а с C++ ABI . При этом все 100 с лишним проходов оптимизаций LLVM никуда не денутся, просто придётся после оптимизаций генерировать С код и собирать С компилятором.
LLVM вообще много чего умеет. Вот только с поддержкой стандартов и gcc-змов не всё до конца ясно, в отличие от того же Comeau.
А ты про что?

anonymous
()
Ответ на: комментарий от tailgunner

* запасаюсь попкорном и жду, кто первый крикнет «gcc-измы не нужны, лучше бы ведро допилили до стандартного C99».

anonymous
()
Ответ на: комментарий от tailgunner

Да там много чего хорошего может выйти.

Например, компактное ядро, собранное с LTO. Наверняка много ошибок в ядре найдут и исправят. Новые тулзы для разработки ядра могут появиться - всякие там call graphs с Clang-ом строить не в пример проще чем с gcc.

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

Был вопрос, «чем оно отличается от Comeau». Вот тем и отличается, что C backend там только для поиграться (он еще и неподдерживаемый, кстати, и очень глючный). И обычных для других backend-ов оптимизаций (того же register allocation) он не делает.

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

ну да, вот например ту приблуду что Линус писал со временем жизни указателей и аннотациями, вдохновившись BitC и Cyclone, вполне можно делать статическим анализатором вроде Klee.

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

> Новые тулзы для разработки ядра могут появиться - всякие там call graphs с Clang-ом строить не в пример проще чем с gcc.

Это уже другой вопрос... понятно, что в роли «библиотечного компилятора» у LLVM конкурентов просто нет. Но меня-то интересует широкое распространение полезных gcc-измов вроде "({".

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

Самые полезные gcc-измы уже давно в clang есть (те же indirect goto targets).

anonymous
()

(26.10.2010 22:21:33):

с помощью Clang удалось собрать работоспособное ядро Linux версии 2.6.36 с поддержкой многопроцессорных систем (SMP)

Работоспособны следующие компоненты ядра:

    Базовый код ядра, файловые системы, поддержка шин, в том числе и PCI, ACPI
    SMP, SMT, SysV, pThreads и POSIX IPC
    NUMA, управление памятью и SWAP
    Сетевой стек IPv4, за исключением IPSec
    Некоторые драйверы и прошивки

Пока не удалось добиться работы следующих подсистем:

    CryptoAPI, а следовательно, и SELinux, Posix ACLs, IPSec, eCrypt
    Стека IPv6 и код Netfilter/Router из-за зависимости от CryptoAPI
    Виртуализации (поддержки гипервизора Xen)
    Поддержки загружаемых модулей
(13.05.2011 16:01:54):
В целом:

    Удалось получить работающую сборку ядер 2.6.37 и 2.6.38 (для некоторых конфигураций)
    KVM и Xen использовать нельзя, причем последний пока даже не компилируется
    Компилируются примерно 90% драйверов ядра, многие работают
    Некоторые поставляемые сторонними вендорами драйвера (Broadcom, NVIDIA) работают отлично
    Можно использовать многопроцессорные конфигурации (правда, только на x86), однако в некоторых случаях они требуют дополнительных усилий по доработке компилируемого кода
Что называется - найдите N отличий.

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

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

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

> И обычных для других backend-ов оптимизаций (того же register allocation) он не делает.

а как ты себе представляешь выделение регистров в C бекенде? наподобие gcc-измов в асм вставках или #pragma aux в Watcom? какой тогда профит именно от С? это уже С компилятор на последней фазе должен делать, по идее.
Опять непонятно. Вот взяли LLVM BC биткод, прогнали его через opt, наложив нужные оптимизации, получив на выходе LLVM BC биткод. Этот последний через C бекенд выгнали в С и собрали С компилятором. Вопрос, что такого должен уметь или не уметь С бекенд, чтобы оптимизации не похерились. Ну то есть вопрос, насколько все эти 10500 оптимизаций composable.

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

> а как ты себе представляешь выделение регистров в C бекенде?

Там переменные регистрами служат. И их генерится до нечитабельности много.

Вопрос, что такого должен уметь или не уметь С бекенд, чтобы оптимизации не похерились.

Навскидку - потеряются tail calls.

Оптимизации backend-а и оптимизации на уровне LLVM IR - это две большие разницы. Проблема cbe в том, что он не стандартный llvm backend, а просто тупо pass.

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

>Очень четкое разделение по уровням абстракции. Легко добавляются произвольные преобразования между этими уровнями. Как результат - есть довольно мощный и легкоуправляемый статистический анализатор кода. Есть полноценная, работающая link time optimization (то убожество, что есть в gcc, еще лет 5 допиливать до рабочего состояния будут).

Ну оочень неочевидные «преимущества». Тем более, они все нивелируются, если вспомнить, что Clang в сравнении с GCC ничего не умеет.

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

> Ну оочень неочевидные «преимущества»

LTO - это «неочевидное преимущество»? Что тогда преимущество, по твоему? Ты вообще хоть что-либо в компиляторах понимаешь, чтобы нести такую чушь? Много своего кода в gcc и в clang закоммитил?

Ну оочень неочевидные «преимущества»

И чего он такого нужного не умеет? Fortran77?

anonymous
()

а как у него с оптимизацией? На сколько хороший и быстрый код выдает по сравнению с gcc? Инлайнить хорошо умеет?

gaga
()
Ответ на: комментарий от Lighting

наоборот, это GCC не умеет, например, блоки http://en.wikipedia.org/wiki/Blocks_(C_language_extension)
ну их можно до какой-то степени эмулировать вложенными функциями, но блоки — это почти полноценные замыкания, в отличие от.

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

В llvm на самом деле никакого даже специального link time optimization не надо, достаточно оптимизации на уровне модулей и линкера, чтобы собрать все модули в один.

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

Не разработчик вообще, поэтому всё это(в том числе и педантичная поддержка стандартов) мне до лампочки, в отличие от скорости и работоспособности скомпилированного кода.

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