LINUX.ORG.RU

Компилятор Clang теперь пригоден для сборки Linux-ядра

 , ,


0

3

В блоге разработчиков Clang появилась информация о том, что с помощью Clang удалось собрать работоспособное ядро Linux версии 2.6.36 с поддержкой многопроцессорных систем (SMP). Несмотря на то, что некоторые компоненты ядра пока не поддаются компиляции, это событие приближает тот момент, когда Clang превратится в полноценный аналог GCC.

Немного технической информации:

  • В качестве основного стенда использовался Macbook 5.1 на базе Intel Core 2 Duo (не стоит забывать, что разработку Clang поддерживает в первую очередь компания Apple). На этой конфигурации удалось запустить ядро с работоспособным X-сервером, а также ядро в среде Qemu
  • В качестве второго стенда использовалась microATX-платформа на базе Intel Atom. В этом случае ядро также функционировало, однако разработчики не пытались запускать X-сервер
  • В системе на базе собранного ядра компилятор успешно собирает сам себя, а также новое ядро. Разработчики докладывают об успешной работе кода, полученного в ходе четвертого цикла самосборки.

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

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

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

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

Разработчики намерены и дальше улучшать совместимость между Clang и GCC и добиваться сборки с помощью Clang полностью работоспособного ядра.

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



Проверено: anonymous_incognito ()
Последнее исправление: Dmitry_Sokolowsky (всего исправлений: 3)
Ответ на: комментарий от anon_666

- компилирет быстрее

Неправда.

Если архитектура старой программы признаётся неисправимо плохой.

gcc тот еще монстр. Его кодоанализатор невозможно в ide встроить и каждое ide свой собственный изобретает. А кодоанализатор от clang'а можно легко использовать.

Хочу еще сказать, что clang развивается заметно быстрее, чем gcc

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

>- bsd-лицензия

это спорный вопрос, преимущество или недостаток. Но то что пилит его не команда gnu очень даже замечательно. Потому что гнутые любят велосипедостроение и кривые решения.

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

>это спорный вопрос, преимущество или недостаток.

Для компилятора - скорее преимущество. Вот для прикладного ПО, на котором деньги зарабатывают, это да, вопрос дискуссионный.

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

>Расскажите вкратце и доступно непрограммеру, в чём Clang лучше GCC

1. модульный, т.е. llvm состоит из кучи мелких кусков, каждый из которых в принципе постижим обычным человеком. 2. он красиво ошибки подсвечивает с точностью до символа.

ну и из минусов то, что пока код он генерирует медленнее и поддержка плюсов, специфичных для gcc расширений и т.п. вещей пока не доведена до отполированного состояния.

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

>ну и из минусов то, что пока код он генерирует медленнее и поддержка плюсов, специфичных для gcc расширений и т.п. вещей пока не доведена до отполированного состояния.

Из минусов у него лицензия.

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

Так скомпилированная программа не является же производной работой от компилятора

Так ведь хочется заюзать анализатор кода от компилятора в IDE для генерации варнингов, подсветки синтаксиса, статического анализа кода. А с gcc никак, причем даже не в лицензии дело, а в какой то Столманновской паранойе, который считает, что проприетарщики в этом случае даже gpl обойдут и намеряно сделал API gcc черезжопу. Не говоря о том, что с помощью llvm можно динамический анализ кода куда круче сделать, чем с gcov

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

Потому что в гцц это все уже давно есть. Придумывать новое всегда сложнее, чем реализовывать старое.

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

>а чем это лучше
а ничем.
по моим тестам, скорости не прибавляет и не убавляет.
тестил lame.

system-root ★★★★★
()
Ответ на: комментарий от annulen

Фигня для блондинок. Вот если бы он умел ошибки в шаблонах нормально показывать...

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

>Gcc фактически закрытый и проприетарный по самое небалуйся.

Всё-таки открытый. Но GPLv3 и странная политика принятия патчей сделают своё дело.

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

> Так скомпилированная программа не является же производной работой от компилятора

В FSF считают иначе. Право использовать скомпилированные gcc программы дают якобы только исключения лицензии.

baka-kun ★★★★★
()
Ответ на: комментарий от pylin

>а как программеру ну да денежек содрать побольше можно)

поясни?

на рантайм у жцц претензий к закрытому коду нет.

или ты компиляторы пишешь?

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

> Всё-таки открытый.

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

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

4.2. Те искючения, которые ты имеешь в виду, на runtime-библиотеки (glibc, libgcc…), а не на сам компилятор.

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

> Расскажи это интел, например.

Штеуду интересен компилятор не очень конкурирующий с их собственным. И да, они та самая часть GNU сообщества (местами).

baka-kun ★★★★★
()
Ответ на: комментарий от samy_volosaty

> я так понимаю исключения добавили для устранения недоговорённости.

То есть я уже могу взять результат работы первой стадии компилятора, модифицировать по своему усмотрению, скормить кодегенератору, и получить НЕ GPL продукт? FSF так не считает.

baka-kun ★★★★★
()
Ответ на: комментарий от Ttt

> Те искючения, которые ты имеешь в виду, на runtime-библиотеки

А если повнимательней приглядеться?

baka-kun ★★★★★
()
Ответ на: комментарий от Gorthauer

> Так ведь хочется заюзать анализатор кода от компилятора в IDE

Анализатор кода от компилятора для IDE никак не подходит - хоть от clang, хоть от gcc, потому что он должен быть:

a) Инкрементальный

b) Уметь парсить неправильный код (т.е. успешно парсить в принципе произвольный текст).

Ничего этого парсеры компиляторов делать не умеют.

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

> - компилирет быстрее

- более внятные сообщения об ошибках

- bsd-лицензия



Недостатки:
- не весь код переваривает
- обычно генерит код на пару процентов быстрее gcc, но иногда может и сотворить что-то ужасно тормозящее
- bsd-лицензия. Хорошо это или плохо пусть решаю тролли, мы же упомянем и в преимуществах и в недостатках.

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

> не весь код переваривает

поправят, хотя и не обязаны. Отхождения от стандарта - это проблемы программистов. Это редкий случай, когда apple идет на встречу.

обычно генерит код на пару процентов быстрее gcc, но иногда может

Как и gcc. Вопрос тюнинга.

Технически gcc хуже. Просто старее

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

> - не весь код переваривает

Это не надолго. Предрекаю: достаточно скоро в gcc будут пилить совместимость с clang.

- обычно генерит код на пару процентов быстрее gcc, но иногда может и сотворить что-то ужасно тормозящее

Он очень быстро развивается.

baka-kun ★★★★★
()
Ответ на: комментарий от namezys

>Технически gcc хуже. Просто старее

Ох лол. Ты хоть пару строк гцц видел? Аналитик, епт. За время развития гцц обрел вполне себе нормальную архитектуру, которая позволяет его спокойно расширять. То, что ллвм что-то там быстрее генерит - бред, не видел ниодного реального теста.

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

>Так скомпилированная программа не является же производной работой от компилятора

Ну да. А причем тут это?
Я говорю, что для компилятора не суть важны различия между gpl и bsd, так как код компилятора вряд ли кто будет использоваться в закрытых коммерческих продуктах.
Что с gpl вообще противозаконно, то в данном случае просто очень маловероятно.
В то же время привлекательность использования этого компилятора в каких-нибудь закрытых внутрикорпоративных IDE, которым вирусность GPL поперек горла, заметно повышается.

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

Ох ты ж ё, как-то весь срач мимо меня прошел, припозднился с ответом.

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

Так зато правда же. Больше половины проектов гну - велосипеды под «правильной» лицензией. Так что наличие велосипедов под неправославной лицензией должно положительно сказаться на их ЧСВ.

Ну а кривость gcc - предмет холиваров. Некий Линус вот высказывался когда команда gcc в очередной раз поломала свои же хаки что если бы он знал что с этими чудаками ему придется работать то сразу писал бы ядро на паскале

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

> Ну а кривость gcc - предмет холиваров. Некий Линус вот высказывался когда команда gcc в очередной раз поломала свои же хаки что если бы он знал что с этими чудаками ему придется работать то сразу писал бы ядро на паскале

Ссылку можно?

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

Пожалуйста

Линус Торвальдс достаточно нелестно отозвался о некоторых опциях показа предупреждений (warnings) в GCC, говоря о том, что реализация многих из них просто не учитывает желания программиста и реальные проблемы. Тем неменее, некоторые из предупреждений очень полезны и используются при сборке ядра. Линус также отметил, что язык C не совершенен и для написания абсолютно безопасного кода он бы выбрал Паскаль.


http://www.linux.org.ru/news/linux-general/1676527

Согласно изменениям, которые произошли с выпуском ядра 2.6.16-rc1 (http://kernel.org/pub/linux/kernel/v2...), компиляторы GCC < 3.3.0 для сборки Линукса более не поддерживаются. Линус Торвальдс также посоветовал не использовать GCC версий 4.0.1 и 4.0.2, т.к. они плохо собирают код с оптимизацией -Os.


http://www.linux.org.ru/news/kernel/1235123

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

> Линус также отметил, что язык C не совершенен и для написания абсолютно безопасного кода он бы выбрал Паскаль.

Линус этого не говорил. В оригинале его фраза звучала так: «the C language has scoping rules for a reason. If I wanted a language that didn't allow me to do anything wrong, I'd be using Pascal. As it is, it turns out that things that 'look' wrong on a local level are often not wrong after all.»

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

Спасибо за ссылки, интересно. Вот только одно уточнение: реплика Линуса про паскаль никак не относится к проблемам именно GCC. Линус сказал следующее: If I wanted a language that didn't allow me to do anything wrong, I'd be using Pascal. Что примерно переводится как: «Если бы я хотел использовать язык, который не даст мне сделать что-либо неправильно, я бы использовал Паскаль». Проблемы GCC отдельно, проблемы языка Си отдельно. Просто так получилось, что они в одном посте.

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

И я не согласен с тем, что Паскаль безопасный язык. Массивы есть (без автоматической проверки границ), указатели есть: говнокодеры к сегфолтам готовы.

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

Gorthauer> Так ведь хочется заюзать анализатор кода от компилятора в IDE для генерации варнингов, подсветки синтаксиса, статического анализа кода. А с gcc никак, причем даже не в лицензии дело, а в какой то Столманновской паранойе, который считает, что проприетарщики в этом случае даже gpl обойдут и намеряно сделал API gcc черезжопу.

Шо??? Я вполне могу написать проприетарную программу, собрать её с GCC, и она свободной от этого не станет. А использование компонентов GCC - это уже производная работа от компилятора.

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

baka-kun> Он сейчас напрочь огорожен от принятия улучшений и развития кем-либо за пределами части сообщества GNU.

Во-первых не огорожен, а просто проприетарщикам не нравится GPL.
Во-вторых: открытый - не означает, что в апстрим тебе дадут пихать что попало. Разработчик вправе решать, что в апстрим пускать. И даже вправе вообще ничего в апстрим не пускать со стороны. Но и в этом случае открытым (и уж тем более свободным) проект быть не перестаёт по определению.

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

baka-kun> То есть я уже могу взять результат работы первой стадии компилятора, модифицировать по своему усмотрению, скормить кодегенератору, и получить НЕ GPL продукт?

Если тебе так нравится прищемлять свои же яйца дверью - что ты тогда делаешь на ЛОРе?

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

namezys> Технически gcc хуже. Просто старее

Ну нифига себе. Теперь время, когда код написан, сало технически параметром? Это параметр только для торсионщиков.

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

Здрасьте, давно уже есть и проверки диапазона массивов и многое другое.

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

>Так ведь хочется заюзать анализатор кода от компилятора в IDE для генерации варнингов, подсветки синтаксиса, статического анализа кода.

А в чем проблемы? Конечно придется немного напильником пройтись но исходники все на C и вполне себе неплохо организованы. Тем более что не весь же gcc тащить а только его g++ часть из которой нужен лишь cp.

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

> А в чем проблемы?

IDE хочется закрытую иметь.

Тем более что не весь же gcc тащить а только его g++ часть из которой нужен лишь cp.

у gcc нет статического анализа. а obj-c достаточно динамичен

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

>IDE хочется закрытую иметь.

Проблемы негров... ну вы понимаете. Хотя для всяческих жлобсов этот довод конечно решает.

у gcc нет статического анализа

Не совсем понимаю зачем это нужно в IDE но, в любом случае, изначально речь шла о синтаксическом анализаторе.

A-234 ★★★★★
()
Ответ на: комментарий от namezys

> IDE хочется закрытую иметь.

в этом-то всё и дело. проприетарщики такие проприетарщики: gcc им не нравится тем, что он открыт и свободен.

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

> Не совсем понимаю зачем это нужно в IDE но, в любом случае, изначально речь шла о синтаксическом анализаторе.

У меня есть объект. Какие у него методы?

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

> проприетарщики такие проприетарщики: gcc им не нравится тем, что он открыт и свободен.

gcc не нравится тем, что не позволяет делать то, что они хотят. Этого достаточно

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

>gcc не нравится тем, что не позволяет делать то, что они хотят. Этого достаточно

ты мне не позволяешь лазить в твой холодильник - фу, ГПЛьщик натииииивный!... =)

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

он должен быть:

a) Инкрементальный

b) Уметь парсить неправильный код (т.е. успешно парсить в принципе произвольный текст).

Ничего этого парсеры компиляторов делать не умеют.

Парсер у компилятора в Eclipse JDT умеет это делать, не зря IBM в это столько ресурсов вложила.

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

> Парсер у компилятора в Eclipse JDT умеет это делать

clang тоже. Еще и варианты исправления предлагает

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

> Фигня для блондинок. Вот если бы он умел ошибки в шаблонах нормально показывать...

кое-где в шаблонах уже показывает намного лучше, чем жцц

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

Хммм... Давно уже не использовал подобные IDE но эта фича конечно вроде бы должна быть удобной. Конечно можно привести можество примеров из реальной жизни когда такую фичу ни одна IDE реализовать не сможет но это было бы занудством поскольку подобные примеры есть скорее исключение нежели правило.

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

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