В списке рассылки разработчиков LLVM публично анонсирован (http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/05...) проект LLVMLinux (http://llvm.linuxfoundation.org/), созданный под покровительством организации Linux Foundation для обеспечения сборки ядра Linux с использованием компилятора Clang. Проект LLVMLinux сформирован на основе ряда разрозненных инициатив, в рамках которых осуществлялись попытки решения проблем при сборке ядра с использованием Clang. В частности, учтены наработки проекта lll-project (https://github.com/lll-project), команды разработчиков PAX (http://pax.grsecurity.net/) и консорциума Linaro (http://www.linaro.org/).
Создатели LLVMLinux надеются, что консолидация смежных разработок в единый проект позволит избавиться от дублирования работы и даст возможность сконцентрироваться на решении важных задач, что в итоге ускорит появление полноценной поддержки Clang, как сборочного инструментария, альтернативного GCC. В частности, использование компилятора Clang, распространяемого под лицензией BSD, позволяет задействовать дополнительные техники оптимизации и диагностики проблем, например, автоматизировать выявление фактов разыменования указателей и других ошибок, связанных с некорректной работой с памятью.
Отправной точкой LLVMLinux послужила работа по задействованию Clang для сборки ядра Linux для платформы ARM, выполненная консорциумом Linaro в рамках инициативы по улучшению поддержки архитектуры ARM в Linux. На основе порта для ARM (http://llvm.linuxfoundation.org/index.php/ARM) были подготовлены аналогичные порты для архитектур i586 (http://llvm.linuxfoundation.org/index.php/I586) и x86_64 (http://llvm.linuxfoundation.org/index.php/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".
URL: http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-September/05...
Новость: http://www.opennet.me/opennews/art.shtml?num=34811
В арче еще в апреля 2011 собирали - https://aur.archlinux.org/packages.php?ID=48519
> В арче еще в апреля 2011 собирали - https://aur.archlinux.org/packages.php?ID=48519Только после такой сборки половина модулей не работала.
>> В арче еще в апреля 2011 собирали - https://aur.archlinux.org/packages.php?ID=48519
> Только после такой сборки половина модулей не работала.и грузилась система только в консоль, X-ы не стартовали из-за проблем с драйверами.
Только бы не в ущерб производительности, все это специфичны фишечки GCC не просто так использовались
"Использовались". Прошедшее время. Тогда все эти специфичные фишечки GCC создавались потому, что в стандарте Си они отсутствовали. Сейчас, когда многое из необходимого есть в стандарте, использовать специфичные для компилятора решения нет смысла.
Многое используется и сейчас, не надо ля-ля. Нулевые массивы, ожидание ветвления, красивые функции.. Много чего.
массивы 0 длины - в стандарте,
ожидание ветвления - уже удаляют, как-то вот оно больше мешает - чем помогает.Красивые функции? это что такое..
gcc быстрее, но clang надежнее? бросаем-подбираем?
> gcc быстрее, но clang надежнее? бросаем-подбираем?Вообще-то сама возможность рабочей сборки другим компилятором уже стоит очень много. Есть ряд крайне неприятных ошибок, которые на одних компиляторах "плавают", а на других - стабильно воспроизводятся.
Поэтому поддержка несколькими компиляторами сборки ядра Linux только поможет избавлению от ошибок и отладке ядра.
Ну, учитывая что сообщения об ошибках в gcc по сравнению с clang полное уг, это можно только приветствовать. По-хорошему, в ОС вообще не должно быть специфичных для конкретного компилятора конструкций, не дело среды исполнения влиять на стандарты языка.
учитывая, что си создавался для написания юникса, то ваше заявление слегка наивно
>сообщения об ошибках в gcc по сравнению с clang полное угобманывать нехорошо.
Спасибо за ссылку - круто, что ребята из gcc не отстают. Однако, gcc 4.8 еще не релиз, а 4.7 такой красоты еще не печатает, в то время как clang 3.1 - это релиз и ведет себя как написано. Так что указанное выше не обман, а текущее состояние дел, которое впрочем вскоре вполне может измениться.
релиз, не релиз, а сабж он пока не компилирует.
и код у него плохо оптимизированный на выходе.так что если вы априори планируете писать код с ошибками, то да, может быть.
а если планируете качественный, то вам нужен гцц, гдб и прочка профайлеров.
в общем выглядит как отмазка какая-то для начинающих программистов, которые вдруг решили поучить профи.
> релиз, не релиз, а сабж он пока не компилирует.так же как и текущий гцц не показывает таких сведений об ошибке.
> в общем выглядит как отмазка какая-то для начинающих программистов, которые вдруг решили
> поучить профи.Профи, можно ваши проекты увидеть?
можно. а ваши?
очень хочется на ошибки посмотреть, которые важнее производительности и оптимизации.
> можно. а ваши?
> очень хочется на ошибки посмотреть, которые важнее производительности и оптимизации.мисье видимо не читал Кнута и Вирта? ну да.. это не модно сейчас читать в Ылытной молодежи.. главное меряться флагами компилятора и прочими пискомерками.
Мисьме - грамотный подбор алгоритма под задачу, делает такой офигенный прирост производительности - что никакой супер пупер оптимизатор из gcc не сможет дать. Так что можешь продолжать любоваться флагами компилятора - а мы вот лучше займемся правильными алгоритмами...
в психбольнице день открытых дверей?
Спасибо clang, что ребята из gcc начали наконец заботится о нуждах пользователей.
Не-не-не, это 4.8, а в продакшене пока что этой красоты нет.
> http://gcc.gnu.org/wiki/ClangDiagnosticsComparisonинтересно, можно ли будет эту хренотень отключить? подозреваю, что нет. «улучшатели», блин.
Ошибки компиляции - не самые страшные ошибки.
> Ошибки компиляции - не самые страшные ошибки.Да. Более того, для них есть статические анализаторы. Но, блин, встречаются и ошибки, которые не ловятся ни чем. :-(
да тут всё больше про оформление этих ошибок.
а если она не поймана, то и не оформлена :D
> да тут всё больше про оформление этих ошибок.
> а если она не поймана, то и не оформлена :DМы не про ошибки синтаксиса, которые ловятся компилятором. А про сложные ошибки выполнения, которые очень редко ловятся отладчиком.
некоторым важно качество, некоторым скорость, а некоторые сравнивают только лицензию clang vs gcc
))))
и самое главное - все багфиксы и оптимизации в оптимизаторах и "линковщиках" (которые байткод llvm в машинный код) сделанных для clang (компилятора с сей) будут работать для компиляторов со всех жав, D, сишарпов, фортранов и прочего
за счёт этого llvm будет бибикать gccа лицензию таки жалко что не та :(
пффф, эпл как раз и создает этот компилятор, потому что им нужен компилятор именно с "не той" лицензией
цытирую:
"Проблема, как ни удивительно, не в GPL, а в одном копирасте по фамилии... Столлман. РМС, Ричард Метью.В году 2008 он взял и заявил, что бедные покупатели айфонов страдают от своих тивоизированных устройств и их нужно спасти. И тут же сменил лицензию на GPLv3, убрал парочку исключений из лицензии. И получилось так, что Apple теперь не могут компилить свои продукты с гцц версии выше чем 4.2, некоторую другую проприетарщину вроде тоже задело.
Теперь мы имеем clang, который архитектурно превосходит гцц, но сливает в размере кодовой базы и числу оптимизаций; gcc версии 4.2 в макоси; кучу всё также тивоизированных айфонов и недовольство среди разработчиков gcc, которые уже предлагают переделать его наподобие шланга - сделать модульным, под LGPL и постепенно передвигаться C++.А всё потому, что, в отличие от линукса, эксклюзивных прав на который нет ни у кого в мире, GCC целиком и полностью принадлежит FSF - коммитеры явно передавали им права. Как показала практика, напрасно."
анонимус с ЛОР"авот откуда все беды растут, тогда многие компании начали искать альтернативу, ведь известно что clang поддерживают ARM, Google, Sun, Apple ...
полная брехня. http://en.wikipedia.org/wiki/LLVM
>In 2005, Apple Inc. hired Lattner and formed a team to work on the LLVM system for various uses within Apple's development systemshttp://lists.trolltech.com/qt4-preview-feedback/2005-02/msg0...
>Date: Sat, 19 Feb 2005 14:57:49 -0500
>The creator and lead author, Chris Lattner, has just been hired by Apple to work on LLVM. Apple is making a major investment in this compilation strategy.http://en.wikipedia.org/wiki/GNU_General_Public_License#Vers...
>In late 2005, the Free Software Foundation (FSF) announced work on version 3 of the GPL (GPLv3). On 16 January 2006, the first "discussion draft" of GPLv3
>....
>The final version of the license text was published on 29 June 2007первое(!!!) обсуждение GPLv3 появилась с отставанием более чем в 1 год говорит, что анонимус с ЛОР"а либо вообще не дружат с логикой, либо наглоё враньё уже часть его натуры.
типа не соврал, день прошёл зря
> первое(!!!) обсуждение GPLv3 появилась с отставанием более чем в 1 год говорит,
для особо религиозных, сменил != вышла, читать научитесь
по вашему все пошло так мигом, что можно все скинуть в одну кучу и сказать, это было так
а "сменил" - это ещё позже, чем вышла.
как бы очевидно, что вначале вышла GPLv3 и уже потом gcc под этой лицензией.
соответсвенно выод прост - яблоко занялось разработкой llvm/clang задолго того момента, когда РМС о ней думать стал и тем более задолго, когда стал думать о смене лицензии на gcc.ну попробуйте уже напрячь то свой эквивалент логического мышления.
вдруг в жизни пригодится.
> Теперь мы имеем clang, который архитектурно превосходит гцц, но сливает в размере
> кодовой базы и числу оптимизацийЕсть интересные особенности, но говорить про "архитектурное превосходство" это очень наивно. Сколько лет он уже "архитектурно превосходит", а код на выходе унылый. Через склько лет начнете подозревать что не все так просто? Еще месяц и он порвет GCC? Не, после Нового года? Ладно, вот весной уже точняк!
если честно то мне пофиг чем собран дистрибутив или ОС, главное что бы работало, если у кого то к этому религиозные взгляды то я не виноват.
Что мы имеем, clang APPLE использовала для iOS - средствами obj-c, потом случилось что писал выше анонимус с лора, ка известно кроме iOS, ... еще есть МасOS X, и МАС на линукс ядре в котором и применялся GCC.
> Что мы имеем, clang APPLEопячатался LLVM
а это тогда что?
>и МАС на линукс ядре в котором и применялся GCC.тоже очепятка?
есть версия мас с линукс ядром
не слышал такого.
пруф можно?
иди к ембедшикам и расскажи про шланг.
Реально clang относительно молод, но при этом прогресс и скорость его разработки впечатляют. Смотря на то, как разработчики gcc активизировались на разработке давно обещаемых полезных фич можно сказать, что clang для gcc безусловное благо.
что за глупости...
так и мс видимо благо для андроида, а огрызок для самсунга.
черное - это такой оттенок белого и не более, следовательно чёрное - это белое.gcc разрабатывался постоянно с такой скоростью и возможностями.
хоть 20 шлангов выйдет - это никак не увеличит рабочий день сотрудникам.
> gcc разрабатывался постоянно с такой скоростью и возможностями.
> хоть 20 шлангов выйдет - это никак не увеличит рабочий день сотрудникам.Сознательно врешь или просто не знаешь?
egcc видио появлялся просто так...
вы и логика - это видимо вещи совсем ортогональные.
Именно про это я и написал. Давно уже так говорят, а код все такой же неоптимальный.
> на разработке давно обещаемых полезных фичэто идиотский новый формат сообщений об ошибках — чтобы их поменьше на экран помещалось? да уж, супернеобходимая фича. ведь редакторы не умеют позиционировать курсор на строку-символ, без подчёркивания в выхлопе — никак.
Форкай, делов.
форкнуть под другую, не совместимую лицензию нельзя.
> форкнуть под другую, не совместимую лицензию нельзя.Под gpl можно. Только кто его будет разрабатывать?
без понятия.
лично мне не нужна.хотя попытки компилировать ядро приветствую. но толку тут будет больше шлангу, чем ядру, т.к. ядро ещё и пилится интелом (вспоминаем LTO - http://www.opennet.me/opennews/art.shtml?num=34619 ), также их компилятором icc, таже работа идёт в амд (Open64 http://www.opennet.me/opennews/art.shtml?num=32275 ) и ещё рядом заинтересованных компаний.
так что у ядра линукс более чем достаточно и интсрументов для всестороннего тестирования, и желающих это тестирование проводить.
но если и из сабжа придёт хоть крупица улучшений для ядра, то это будет не плохо.так что сабж - это опыт и технологии полезные именно ему (научить компилить ядро, посмотреть результаты, устранить недочёты и тд)
зыж
а вот llvm очень интересен сам по себе.
но это не имеет отношение ни к сабжу, ни к ядрам.
>сделанных для clang (компилятора с сей) будут работать для компиляторов со всех жав, D, сишарпов, фортранов и прочегопусть это прочее вначале появится :D
а то там токо обджси и шланг более менее стандратам соответсвуют
>>сделанных для clang (компилятора с сей) будут работать для компиляторов со всех жав, D, сишарпов, фортранов и прочего
>пусть это прочее вначале появится :D
>а то там токо обджси и шланг более менее стандратам соответсвуюткомпилеры жавы и D на основе gcc тоже никаким стандартам не соответствуют, так что....
зы: и не верится что в них будет ещё и оптимизация кроме сооответствия
следовательно> llvm будет бибикать gcc
вот и выяснили, что не кому и не зачем бибикать. :D
> вот и выяснили, что не кому и не зачем бибикать. :Dвыяснили что написать компилер целиком слишком сложно, а один фронтенд с языка в байткод сильно проще написать
ха! пруфы привести с подавляющим большинством поддерживаемых языков и архитектур по сравнению с gcc можете?
нет? я так и думал.
зыж
и да!
>выяснили что написать компилер целиком слишком сложно, а один фронтенд с языка в байткод сильно проще написатьgcc так всегда и делал! :D
http://gcc.gnu.org/wiki/StructureOfGCC
и кстати, за последние годы отрыв по поддерживаемым языкам и платформам у gcc только увеличился.
> http://gcc.gnu.org/wiki/StructureOfGCCспасибо за ссылку, этого я не знал
Бибикалка у шланга не доросла, чтобы на ГЦЦ бибикать...
Шланг пока для некоторых архитектур генерит код кривой как винт моторной лодки ( я занимаюсь разработкой под ARM/MIPS). Для ARM код кривой, для MIPS, AVR, PowerPC он вообще не умеед код генерить. Давайте уж о эфемерном бибиканье будем говорить, когда оно по числу поддерживаемых архитектур хотя-бы на 70% догонит ГЦЦ.
> Шланг пока для некоторых архитектур генерит код кривой как винт моторной лодки
> ( я занимаюсь разработкой под ARM/MIPS). Для ARM код кривой, для
> MIPS, AVR, PowerPC он вообще не умеед код генерить. Давайте уж
> о эфемерном бибиканье будем говорить, когда оно по числу поддерживаемых архитектур
> хотя-бы на 70% догонит ГЦЦ."Отправной точкой LLVMLinux послужила работа по задействованию Clang для сборки ядра Linux для платформы ARM, выполненная консорциумом Linaro в рамках инициативы по улучшению поддержки архитектуры ARM в Linux. На основе порта для ARM были подготовлены аналогичные порты для архитектур i586 и x86_64." - значит пилят на арм вот прям щас
ну и "В дальнейшем спектр поддерживаемых архитектур планируется расширить (например, добавить поддержку MIPS, PowerPC), если найдутся заинтересованные в подобной работе лица."зы: поддержка арм из коробки получит все компиляторы работающие с ллвм и часть оптимизаторов (не зависящих от архитектуры проца) как только будет запилена, вот что круто.. больше и разных языков на все платформы сразу :)
столько бреда и в одном комментарии. даже и не знаю как это прокомментировать то.
это АНОНС только начала работ.зыж
>поддержка арм из коробки получит все компиляторы работающие с ллвм и часть оптимизаторов (не зависящих от архитектуры проца) как только будет запилена, вот что круто.. больше и разных языков на все платформы сразу :)это новое слово в науке и технике. :D
для тех кто не знает архитектуры gcc.
в общем просвещайтесь - http://gcc.gnu.org/wiki/StructureOfGCC
> это новое слово в науке и технике. :D
> для тех кто не знает архитектуры gcc.
> в общем просвещайтесь - http://gcc.gnu.org/wiki/StructureOfGCCодно слово. Дурак - даже читать не умеешь что там пишут - там указаны функциональные части - но на самом деле gcc монолит.
о-о-о!... безнадёжный случай.
мои соболезнования вашим родителям.
>одно слово. Дурак - даже читать не умеешь что там пишут - там указаны функциональные части - но на самом деле gcc монолит.О_о
> позволяет задействовать дополнительные техники оптимизацииВ каждой новости это пишут. И в каждом бенче видно что с хваленой оптимизацией как-то хреновато :)