Можно ли скомпилировать ядро Linux с чем-то иным, чем gcc

Интересно, удалось ли кому-то скомпилировать ядро Linux с каким-то другим компилятором, чем gcc. Или если кто-нибудь когда-либо пробовал? Вопрос может казаться глупым или академическим, но это возникло, когда я подумал о ответах на следующие вопросы: Являются ли атомы С++ int в архитектуре mips

Кажется, что атомарность некоторых операций зависит не только от архитектуры cpu, но и от используемого компилятора. Итак, интересно, существует ли в мире Linux какой-то компилятор, отличный от gcc, даже существует.

Ответ 1

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

Это не "нет", поскольку для отдельного поставщика/разработчика компилятора, конечно же, невозможно отслеживать расширения gcc, просто точку данных, которая может помочь вам выполнить поиск.

Ответ 2

В какой-то момент tcc будет обрабатываться и run источник ядра linux. Я думаю, что это будет да.

:: Кончик шляпы до эфемер в комментариях.::

Ответ 3

Были предприняты некоторые усилия (и патчи), чтобы скомпилировать раннюю версию ядра 2.6 с icc.

Ответ 4

Разработчики LLVM пытаются скомпилировать его с помощью clang. Мета-ошибка при компиляции ядра Linux с clang содержит более подробную информацию (дерево зависимостей для этой мета-ошибки показывает, как мало осталось).

Ответ 5

Угу. Я сделал это. См. [cfe-dev] Clang создает рабочее ядро Linux (Boots to RL5 с SMP, сетевыми и X, собственными хостами).

Ответ 6

IBM-компилятор смог сделать это с некоторыми версиями Linux назад, но сейчас я не уверен, и я не уверен, насколько IBM оптимизировала ядро в соответствии с инструкциями. Все, что я знаю, они его создали.

Поскольку Linux является самостоятельным хостингом (со своим собственным libc) и был разработан с самого начала с помощью gcc (и gcc cross compilers), его вроде глупо использовать что-либо еще.

Я думаю, в основном, играя хорошо с макросами препроцессора, и инструктированные оптимизации - это самое большое препятствие (даже не попадание в отход от газа), поскольку GNU в основном написала книгу по вышесказанному и расширила ее. Кроме того, Linux настраивает свои оптимизации для работы с gcc, например, не поймается с использованием "volatile" в ядре без лишней веской причины. Использование inline и фактическое согласие с компилятором - еще одна проблема.

Linus является первым вызовом GCC an & * # $hole, что делает лучший компилятор.

Вот почему у нас большие дискуссии по GNU/Linux.

Ответ 7

Много-много-много лет назад на самом деле было возможно скомпилировать ядро с g++, и насколько я помню часть мотивация заключалась в том, что С++ имел более сильную проверку типа, не обязательно иметь g++ для создания объектных файлов. Но, как указал Нил Баттерворт, Линус не определен любит С++, и нет никаких шансов, что это снова станет возможным.

Ответ 8

Компилятор EKOPath 4, а не сейчас. но, вероятно, с некоторыми незначительными патчами

https://github.com/path64/repositories

http://www.pathscale.com/ekopath-compiler-suite

Ответ 9

Я только сейчас работаю над компиляцией ядра Linux, используя Open64 для MIPS archtecture, и некоторые другие ребята теперь просто работают над тем, чтобы Open64 мог строить для архитектуры X86. Теперь ядро может частично работать и все еще иметь ошибки прогона Run.

Однако для атомной проблемы, по крайней мере, я не придумал ее. И я не думаю, что это действительно проблема. Причины таковы:

Ядро Linux уже представляет собой набор исходных кодов, которые могут успешно создаваться с помощью GCC, поэтому проблема с компилятором может быть только в том случае, если он не может его создать, или сработало выполнение ядра.
Если компилятор хочет успешно создать ядро Linux, он должен обладать расширением GNU C, и это расширение даст четкое описание того, что такое атомная операция, поэтому такой компиляции необходимо генерировать код в соответствии с это расширение.

Ответ 10

Мое нетехническое предположение: Ядро Linux не может в настоящее время (2009) компилироваться с любым компилятором, отличным от компилятора GNU, gcc.

Я говорю это на основании того, что я слышал Ричарда Столлмана, с некоторой убежденностью, сказать, что Linux следует называть GNU/Linux, потому что ядро "всего 1 часть операционной системы", и я предполагаю, что он не сможет сказать этого, если ядро не зависело от GNU (например, тонна встроенных устройств запускает ОС Linux без какого-либо программного обеспечения GNU).

Как я уже сказал, просто догадайтесь, дайте мне знать, если я ошибаюсь...