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 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.