Működő Linux kernel fordítható a Clang-gal

Kernel

Bryce Lelbach közölte nemrég a cfe-dev levelezési listán, hogy a Clang segítségével (többé-kevésbé) működőképes (2.6.36, SMP) Linux kernelt lehet fordítani. A lefordított kernel képes Runlevel 5-re (X + hálózat) bootolni valódi hardveren (MacBook + Debian környezet), illetve Qemu-ban is. A kernel képes "self-host"-ra, azaz a Clang-gal fordított kernelen lehet Clang-gal kernelt fordítani.

A bejelentés részletesen kitér az elért eredményekre. A kernel nagyobb alrendszerei (a core dolgok, a SMP, SMT, Numa, IPv4 hálózati stack, eszközmeghajtó programok stb.) nagyobb probléma nélkül fordulnak. A Clang-gal fordított kernelen működik az X, a hang és Lelbach képes volt Flash player-rel tavalyi BoostCon videókat megnézni.

Persze voltak/vannak még problémák. Voltak olyan nem alapvető kernelkomponensek, amelyek kezdetben nem, vagy nem teljesen jól fordultak le. Ilyen például a SELinux és a Crypto API-t használó dolgok, a virtualizáció és a modulkezelés.

Azok közül, ami tegnapelőtt még nem működött, tegnapra több is a javulás útjára lépett. Lelbach közölte, hogy a SELinux nagy része fordul, lefordul a teljes hálózati alrendszer, szintén lefordul a VDSO, a boot alrendszer, működik már a modul támogatás, a fennálló SMP problémák megoldódni látszanak. A gcc-re már nincs szükség a fordítás teljes ideje alatt, viszont a GNU ldd-re igen. A GNU assembler sem szükséges már a sikeres fordításhoz.

( Joejszaka v | 2010. 10. 27., sze – 09:52 )

Nagyon jó.

Ami ahhoz kell, hogy érdemben érdemes legyen clang-gal foglalkoznom:
- a fordított kód legalább olyan gyors legyen, mint a gcc-vel fordított
- támogasson sok architektúrát.

Az első feltételhez nem tudok hozzászólni, mert még nem teszteltem.
De rá lehet beszélni, hogy még linkeléskor is optimalizáljon :-) Ügyes.

ARM-ra rendszeresen fordítok CLANG-gal, és jól fordít. A többi architektúrát csak nézegettem, de nem kellett varázsolni ahhoz, hogy működjön.

Fuszenecker Róbert

Néztem PIC16-ra is, de igazából nem vagyok nagy PIC-es.

Én úgy szoktam fordítani, hogy a C/C++ fájlokat először virtuális kódra (vagy bájtkódra; nem tudom, minek nevezi pontosan) fordítom, majd linkelem, és a legvégén fordíttatom "natív" assembly-re.
Ezért van az, hogy kipróbáltam legalább 5 architektúrára, mert igazából csak az utolsó lépésnél kell eldöntenem, hogy mire is fordítok.
A "natív" assembly-t pedig megeszi az *as (arm-none-eabi-as), vagy esetünkben a PIC assemblere.

Fuszenecker Róbert

P.S. Ezt találtam itt:

$ mcc16 -dry-run foo.c bar.c
clang-cc foo.c -o /tmp/llvm_6ibgr9/foo.bc
clang-cc bar.c -o /tmp/llvm_6ibgr9/bar.bc
llvm-ld /tmp/llvm_6ibgr9/foo.bc /tmp/llvm_6ibgr9/bar.bc \
-o /tmp/llvm_6ibgr9/tmp.bc
llc -f /tmp/llvm_6ibgr9/tmp.bc -o /tmp/llvm_6ibgr9/tmp.s
native-as /tmp/llvm_6ibgr9/tmp.s -o /tmp/llvm_6ibgr9/tmp.o
native-ld /tmp/llvm_6ibgr9/tmp.o -o a.out

Nem teljesen pontos, de a lényeget ez is jól mutatja.

( Replaced | 2010. 10. 27., sze – 11:04 )

dehat a clang folosleges, mikor van mar gcc

--
NetBSD - Simplicity is prerequisite for reliability

leforditom, annak aki esetleg nem ertette volna: ha freebsd clang-ot rak base-be, vagy szereny szemelyem pkgsrc-hez csinal clang tamogatast, akkor az hulyeseg, folosleges, ha viszont linux-szal kerul egy mondatban emlitesre, akkor hirtelen nagyon jo, erdekes es kivanatos lesz a dolog, etc.

--
NetBSD - Simplicity is prerequisite for reliability

( csabka v | 2010. 10. 27., sze – 12:38 )

Nem tudom mennyire "nagy" hír... valszínű mert nem értek a clanghoz -sem-...

minden esetre akkor mosolyognék, ha .net -el vagy mono-val fordítana vki sikeresen Linux kernel portot :D.

Üdv:
Cs

Valószínűleg valóban egyszerűbb trollkodni a linugz kernellel, mintsem elgondolkodni, hogy eszébe jutott-e valakinek már valakinek menedzselt nyelvben alacsonyabb szinten is dolgozni.

Kit érdekel a linux kernel? Előbb-utóbb az is a múlt lesz az összes Unix koncepciókkal együtt (és megy vele a mai értelemben vett Windowsok is) és fel fogja váltani valami új. Lehet, hogy 20-30 év múlva, de el fog avulni.

----------------
Lvl86 Troll

Kerdes mit ertunk egy dolog elavulasa alatt. Ha csak a "Linux" vagy "Windows" mint nevet, akkor nehez ezt megfogalmazni, mert esetleg lassu (persze lehet hirtelen "gyors" is) valtozasok miatt 20-30 ev alatt esetleg totalisan maskepp fog kinezni a dolog, mint amit ma a fenti nevek alatt ertunk, esetleg alapkoncepciot is tekintve ...

( whitehawk v | 2010. 10. 27., sze – 14:08 )

Nem teljesen értem ezt az LLVM dolgot.

Jól értem, hogy végül is ez egyfajta backend különböző nyelvekhez? Ha jól látom a google python interpretert épít rá pl.

Ezzel lehet gépi kódot is csinálni meg vm kódot is akkor?

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

http://en.wikipedia.org/wiki/Compiler
http://upload.wikimedia.org/wikipedia/commons/6/6b/Compiler.svg

This front-end/middle/back-end approach makes it possible to combine front ends for different languages with back ends for different CPUs. Practical examples of this approach are the GNU Compiler Collection, LLVM, and the Amsterdam Compiler Kit, which have multiple front-ends, shared analysis and multiple back-ends.

gyakorlatilag modularizalva van a forditas.
vannak frontendek, amik mindenfele nyelvbol tudnak a backend szamara ertelmezheto koztes nyelvre forditani, igy egy-egy frontendnek csak adott nyelv(ek)rol koztesre kell tudnia forditani.

a backend pedig csak errol a koztes nyelvrol tud forditani, viszont mindenfele CPU-ra/architechturara.

sokkal egyszerubb igy az elet, mintha 1 programnak kellene minden nyelvrol minden architechturara forditani.

Tyrael