LINUX.ORG.RU

Продемонстрирован запуск openSUSE с ядром Linux, собранным при помощи Clang

 , , ,


0

2

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

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

Для упрощения формирования сборочного окружения и кросс-компиляции ядра с использованием Clang и LLVM подготовлен специальный сборочный инструментарий.

Сборка ядра для архитектур i586 и x86_64 полностью работоспособна и позволяет получать рабочие системы, что демонстрирует пример openSUSE, но официально подобные ядра пока не готовы для применения в конечных продуктах.

Дополнительно налажен ежедневный процесс сравнительного тестирования при помощи пакета Linux Test Project (LTP) свежих сборок ядра, собранных с использованием GCC и Clang.

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



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

главное чтобы нововведения дали оптимизацию и упрощения, без потери наработанной базы

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

Не такая отимизация, которую может дать компилятор :D

Ну так собери себе ядро с -O0 -fno-inline на локалхосте в таком случае.

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

этот же gcc имеет свойство падать с make -j8 при компиляции QtCreator

Ох лол, он у тебя «падает» не от нехватки ли памяти? :D

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

ещё парочка доступна, если в качестве фронтэнда для ллвм использовать всё тот же гцц вместо шланга

Ссылку. От фронтэнда поддержка архитектур зависеть не должна.

dmfd
()

нахрен нужно? типа, быстрее компилит? так если в этот огрызок добавить все фичи, поддерживаемые gcc, он будет компилить с такой же скоростью

короче, недоразумение какое-то

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

Вы когда работать то начнёте?

иди и работай, если тебе это нравится :D

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

Что плохого в BSD/MIT лицензии?

Недостаточная защита от «интеллектуальной собственности».

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

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

И в чем профит?

Показать, что clang дорос до десктопа, обеспечить пересборку им всего дистрибутива, применить анализаторы кода из llvm к ядру, etc.

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

И в чем профит?

Показать, что clang дорос до десктопа, обеспечить пересборку им всего дистрибутива

Это не профит, а затраты.

применить анализаторы кода из llvm к ядру

И как, применили? Много ошибок нашли?

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

Это не профит, а затраты.

пересборка дистрибутива clangом вполне может в какой-то момент стать профитом, по крайней мере gcc47-патчей как-то излишне много на мой взгляд.

И как, применили? Много ошибок нашли?

ну пока просто зафиксили то, что применить мешает.

dn2010
()

Жаль, что лицензия не та, хотя если совместима с GPL (точно не помню), то пусть.

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

В clang C++11 очень даже не плохо работает

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

Это хорошо, что есть альтернатива gcc. Я считаю, что истиная свобода - в возможности выбирать из нескольких альтернатив. Нравится gcc - бери его, нравится clang - бери его.

19 секунд на загрузку ядра (до передачи управления init) на восьмиядерном процессоре. Вот это скорость! Sorry. У меня наверное кривые руки, раз ядро генту на моём Atom N270 грузится за 2.89 сек. - Почти в семь раз быстрее...

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

А ябблкапс зачем? А ябблвебкит?

Принтером я не пользуюсь, я против вырубки деревьев. Яббловебкит я презираю так же, как и ябблошланг, Gecko - наше всё!

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

То есть т.к. лично тебе принтер не нужен, нормально встраиваемый в программу браузерный движок не нужен и приятный процесс разработки на C++ тоже не нужен, то они объявляются вне закона и отныне нинужны никому.

Типичненько.

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

GCC рулит, CLANG помогает.

возникает вопрос: почему кернел завязан на compiler specific kludges?

Я буду продольжать пользоваться GCC, но развитию CLANG'а рад. Наличие нескольких полноценных компиляторов поможет создавать более качественное ПО.

Camel ☕☕☕
()
Ответ на: комментарий от kranky

А в каких компиляторах, кроме GCC, эти же нестандартные расширения присутствуют?

icc, suncc, теперь вот clang. Может еще какие-то проекты помельче.

И какие крупные проекты, кроме Linux, используют эти же нестандартные расширения? Или их таки держат только ради ядра?

glibc, util-linux — из тех чей код я видел. Их много кто использует, т.к. расширения не просто так придумываются.

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

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

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

Во-первых, их поддерживают в той или иной степени все, кроме MSVC.

Во-вторых, проблемой стандартных аттрибутов станет именно MSVC - ага, эти ребята, которые додумались назвать макрос из windows.h (ключевого инклуда системы!) не GMAX, не windows_max, не ms_max, а просто max, и теперь у них конфликт со стандартной библиотекой C++, а все прочие должны прогибаться под их эго. С аттрибутами и расширениями языка та же история - их делают с учётом потребностей своей системы, что само по себе не плохо, но наплевав на остальных, что печально.

В MSVC есть конвенции о вызовах функции stdcall, cdecl, thiscall, fastcall. В gcc они тоже есть. Но в gcc есть ещё две конвенции для других архитектур за пределами x86, а msvc на такое пофигу глубочайше.

В-третьих, включили в 2011-й.

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

Я очень не люблю clang и llvm. Во-первых, потому что не GPL. Во-вторых, потому что очень ограниченная поддержка архитектур. В-третьих, потому что все эти бредни вокруг этого отвлекают от Бриллианта — а именно, GCC.

Вообще-то clang обязан своим появлением кривости gcc.

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

Вообще-то clang обязан своим появлением кривости gcc.

Если в результате gcc станет менее крив - чем не повод «любить, холить и лелеять» clang, пусть даже никогда им и не пользуясь? :D

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

icc, suncc, теперь вот clang. Может еще какие-то проекты помельче.

был тут один псих который пилил компиляцию ядра во время загрузки. ну и где он?

exception13
()
Последнее исправление: exception13 (всего исправлений: 1)
Ответ на: комментарий от AVL2

а любые оптимизации предполагают наличие поддержки в компиляторе.

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

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

знаменитая проблема с тормозами ввода-вывода, когда активная запись на HDD тормозит все остальное - именно кривой алгоритм.

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

Это не профит, а затраты.

пересборка дистрибутива clangом вполне может в какой-то момент стать профитом

...а пока - только расходы.

Ничего не имею против LLVM (на нем уже куча бэкендов написана), но пересборки дистра Clang'ом - какое-то баловство, ИМХО.

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

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

icc умеет выделять в коде паттерны и заменять их на свой код. Например копирование данных в цикле на memmove. Может быть и пузырьковую сортировку превращать в qsort умеет, не проверял. :)

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

icc умеет выделять в коде паттерны и заменять их на свой код. Например копирование данных в цикле на memmove. Может быть и пузырьковую сортировку превращать в qsort умеет, не проверял. :)

вот не надо такого в ядре например.

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

Ну да, а потом получается как в анекдоте про миллиард китайцев и пароль «мао цзедун».

anonymous
()

интерестная новость, спасибо. ничего не знаю на счёт качества реализации clang ибо не пользуюсь, но сама идея llvm мне нравится. имхо за ней будущее.

nanoolinux
()

Продемонстрирован запуск ненужно с ядром Linux, собранным при помощи ненужно

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

даже в генте, почти все бинарники компилятся с -O2 и больше ничем

Очевидно, ты ничего не знаешь про генту.

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

В твоем уютненьком GNU/Linux уже есть ябблкупс.

Они купс не писали а только портят.

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

К разговору о ядре это не относится - там с алгоритмами всё в порядке.

да, верно. алгоритм 12309 идеален и никто ничего менять не собирается.

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

Ничего не имею против LLVM (на нем уже куча бэкендов написана), но пересборки дистра Clang'ом - какое-то баловство, ИМХО.

Отловить человеческие ошибки и куски индусского кода --- тоже баловство?

dn2010
()

Больше компиляторов халявных и открытых!

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