LINUX.ORG.RU
ФорумTalks

Зачем они это делают?

 , ,


0

3

В списке рассылки разработчиков LLVM публично анонсирован проект LLVMLinux, созданный под покровительством организации Linux Foundation для обеспечения сборки ядра Linux с использованием компилятора Clang. Проект LLVMLinux сформирован на основе ряда разрозненных инициатив, в рамках которых осуществлялись попытки решения проблем при сборке ядра с использованием Clang. В частности, учтены наработки проекта lll-project, команды разработчиков PAX и консорциума Linaro.

Создатели LLVMLinux надеются, что консолидация смежных разработок в единый проект позволит избавиться от дублирования работы и даст возможность сконцентрироваться на решении важных задач, что в итоге ускорит появление полноценной поддержки Clang, как сборочного инструментария, альтернативного GCC. В частности, использование компилятора Clang, распространяемого под лицензией BSD, позволяет задействовать дополнительные техники оптимизации и диагностики проблем, например, автоматизировать выявление фактов разыменования указателей и других ошибок, связанных с некорректной работой с памятью.

Отправной точкой LLVMLinux послужила работа по задействованию Clang для сборки ядра Linux для платформы ARM, выполненная консорциумом Linaro в рамках инициативы по улучшению поддержки архитектуры ARM в Linux. На основе порта для ARM были подготовлены аналогичные порты для архитектур i586 и x86_64. В дальнейшем спектр поддерживаемых архитектур планируется расширить (например, добавить поддержку MIPS, PowerPC), если найдутся заинтересованные в подобной работе лица.

Проект LLVMLinux охватывает два направления - решение проблем в ядре Linux при сборке с использованием Clang (уход от использования GNU-расширений, специфичных для GCC)) и адаптация Clang для особенностей ядра. Созданные разработчиками LLVMLinux патчи активно продвигаются в upstream-проекты - ядро Linux и LLVM/Clang. В конечном итоге, планируется из коробки обеспечить формирование полностью работоспособных Clang-сборок ядра Linux, а также обеспечить работу тестового окружения для постоянного мониторинга за появлением регрессивных изменений, проявляющихся при сборке в Clang.

Для упрощения формирования сборочного окружения и кросс-компиляции ядра с использованием Clang подготовлен специальный сборочный инструментарий. Сборки ядра для архитектур ARM, i586 и x86_64, за редким исключением, полностью работоспособны и позволяют получить рабочие системы, но ещё требуют большой работы по тестированию и выявлению неявных проблем, поэтому подобные сборки пока не рекомендуются для применения в конечных продуктах.

Из наблюдаемых при сборке ядра с использованием Clang проблем, которые пытается решить проект LLVMLinux, отмечаются:

  • Использование массивов переменной длины в некоторых структурах ядра (SELinux, Posix ACL, IPSec, eCrypt);
  • Kbuild, который завязан на особенностях GCC;
  • Использование явных регистровых переменных;
  • Использование расширенных аннотаций __refdata;
  • Применение EXPORT_SYMBOL в inline-функциях;
  • Вывод в Clang сообщений об ошибках из-за переопределения POSIX-функций в ядре;
  • Использование неподдерживаемых в Clang флагов компиляции: "-fdelete-null-pointer-checks", "--fno-inline-functions-called-once", "--Wno-unused-but-set-variable" и "--mabi=aapcs-linux".


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

Обеспечивают возможность выбора.

daemonpnz ★★★★★
()

GCC - он же ГНУ! Под Столмана копают, выполняют заказ буржуазного правительства.

abraziv_whiskey ★★★★★
()

Созданные разработчиками LLVMLinux патчи активно продвигаются в upstream-проекты - ядро Linux и LLVM/Clang.

Опять с апдейтами баги прилетят.

Tark ★★
()

начали пилить свой сук?

punya ★★
()

При перепечатке указание ссылки на opennet.ru обязательно

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

в Linux Foundation засланные казачки из бсд.

Прочитал «кабачки». Задумался.

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

Прочитай хотя бы стартовый пост. А потом уже вопрошай.

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

Вот скажите мне, LLVM порой в 2 раза по скорости отстаёт от GCC, что все с ним так носятся?

Сам проверял или Мойша напел?

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

Сам проверял или Мойша напел?

Понял? Не слушай Мойшу, слушай Изю =)

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

Потому что еще очень молодой проект, но плюшек в нем уже очень много.

Ну и конкуренция - это, в любом случае, хорошо.

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

Вот скажите мне, LLVM порой в 2 раза по скорости отстаёт от GCC, что все с ним так носятся?

Ну ему и годков то поменьше будет, чем гцц. допилят совместимость потом и возьмутся за оптимизацию скорости.

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

это clang плохой, или линакс срёт на стандарты?

Оба хорошие.

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

это clang плохой, или линакс срёт на стандарты?

«уход от использования GNU-расширений, специфичных для GCC» - что вам непонятно в этой фразе?

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

Потому что еще очень молодой проект, но плюшек в нем уже очень много.

Ну и конкуренция - это, в любом случае, хорошо.

Плюшки плюшками, но лучше бы они занялись созданием максимально эффективного кода, а уж потом добавляли поддержку C++ 11 и прочего, без чего все до сих пор прекрасно жили (кстати, Open Source проектов, использующих возможности даже C++ 03, практически нет).

В наше время эффективность/производительность кода решает всё. Если у вас неэффективный код, то энергоэффективность падает, а, значит, такой компилятор не нужен ни на планшетах, ни на сотовых, ни на ноутбуках, ни на серверах.

Странно, что люди (в их числе Apple и разработчики FreeBSD) это не понимают.

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

В общем случае clang эффективнее gcc за счет своей модели оптимизации. Ты почему-то решил, что он неэффективен и это культивируеш у себя в голове.

такой компилятор не нужен ни на планшетах, ни на сотовых, ни на ноутбуках, ни на серверах.

В OS X и iOS он уже эффективно применяется.

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

(кстати, Open Source проектов, использующих возможности даже C++ 03, практически нет).

А что там за клевые фичи в 03?
На 11 хотя бы ради auto и for(each) уже можно переходить.

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

В общем случае clang эффективнее gcc

похоже на 4.2, проигрывает он немного - 5-10% в среднем, но проигрывает

// мнение, основанное в том числе на собственных замерах

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

На 95% тестов Clang проигрывает GCC - можете посмотреть на phoronix.

Я лично тоже проверял, но на моих тестах Clang ещё более медленней, чем на тестах Майкла.

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

Значит это я свормировал неправильное мнение у себя в голове.

В Clang/LLVM есть большой задел для будущего развития, очень мощная инфраструктура и куча плюшек статического анализа. Богатый внешний API.

Поэтому и носятся. GCC функционально менее богат.

mono ★★★★★
()

Не надо батхерта. Выбор это круто.

Sociopsih ★☆
()
ac-pro-sergey:~ sergey$ cc --version
Apple clang version 4.0 (tags/Apple/clang-421.0.60) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.4.0
Thread model: posix
mac-pro-sergey:~ sergey$ uname -a
Darwin Mac-Pro-sergey.abak.ru. 11.4.0 Darwin Kernel Version 11.4.0: Mon Apr  9 19:32:15 PDT 2012; root:xnu-1699.26.8~1/RELEASE_X86_64 x86_64
mac-pro-sergey:~ sergey$

Завидуют Apple ???

robot12 ★★★★★
()

В списке рассылки разработчиков LLVM публично анонсирован проект LLVMLinux, созданный под покровительством организации Linux Foundation для обеспечения сборки ядра Linux с использованием компилятора Clang.

Да ты слоупок, он уже давно существует, только раньше назывался LLL.

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

похоже на 4.2, проигрывает он немного - 5-10% в среднем, но проигрывает

Это если под «эффективнее» понимать качество оптимизации. Но «эффективность» может быть и в другом, например в скорости работы качестве диагностик.

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

В наше время эффективность/производительность кода решает всё.

Не правда. Все решает производительность разработчиков (time to market)

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

Это если под «эффективнее» понимать качество оптимизации.

речь шла как раз о ней

Но «эффективность» может быть и в другом, например в скорости работы качестве диагностик.

и именно поэтому «дебажные» билды я делаю clang

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

Разработчики ядра тоже хотят работать продуктивно.

annulen ★★★★★
()

Вообще такое ощущение, что gcc потихоньку загибаться начал. Может и к лучшему, всё же софт нужно переписывать время от времени.

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

То есть у тебя дебажные и релизные сборки делаются разными компиляторами?

да

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

чтобы не отставал. а вообще под ллвм удобнее писать компиляторы.

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

баттхерту кучу. так окей подписался на тег увидел новые посты но спать пора.

Thero ★★★★★
()
Последнее исправление: Thero (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.