Compilador livre Clang está mais próximo de conseguir compilar o kernel Linux
Cerca de 6 meses após conseguir compilar integralmente o FreeBSD, o compilador livre Clang (integrante do projeto LLVM, sob licença NCSA) parece prestes a alcançar mais um marco interessante: Bryce Lelbach divulgou, no grupo dos desenvolvedores do Clang, que com algum esforço já conseguiu compilar com sucesso parte considerável do kernel Linux, e em algumas semanas espera conseguir completar o suporte.
O kernel Linux é historicamente compilado com o GCC, e usa extensões desenvolvidas especificamente no âmbito deste compilador, o que é uma razão a mais pela qual se torna um alvo interessante para testar a capacidade e compatibilidade de outros compiladores: os testes e esforços feitos com o não-livre ICC, da Intel, como os mostrados neste paper, são bastante ilustrativos e detalham inclusive algumas das peculiaridades do tratamento que o GCC dava ao código do kernel na época.
Naturalmente, em seus testes com o Clang, Bryce também encontrou peculiaridades similares, inclusive uma que se manifesta em todas as áreas do kernel relacionadas a criptografia (que até o momento ainda estão pendentes de solução).
Mas o kernel hibridamente compilado com o Clang pelo Bryce tem suporte a bastante coisa: roda o Debian no notebook dele em runlevel 5 (boot completo multiusuário em modo gráfico e com rede IPv4), com os filesystems, ACPI, PCI, SMP, POSIX IPC, pthreads, NUMA, swap IPV4, os drivers necessários, suporte a som, webcam, usb, touchpad, drive de DVD, teclado e gráficos – o kernel compilado por ele rodou até mesmo o Flash player para assistir a vídeos.
E o mais interessante: embora o conjunto ainda não esteja 100% self-hosted (porque o Clang não conseguiu compilar o kernel completo), o kernel compilado por ele foi capaz de permitir compilar novamente um kernel igualmente funcional, usando o Clang rodando sobre si.
Além das questões relacionadas aos códigos de criptografia, ainda há outros, incluindo problemas específicos no carregamento de módulos, e especialmente 2 outros previamente conhecidos (relacionados a assembly inline feito do “jeito GCC”) que no momento foram resolvidos via compilação específica com o GCC destes 2 trechos.
Estes problemas listados já estão em variados graus de solução, em sua maioria por meio de mudanças no comportamento do Clang, embora o histórico demonstre que projetos em condições similares aceitaram de bom grado patches para remover situações que ox tornavam compatíveis apenas com o GCC.
Em paralelo, o Bryce está portando alguns kits de testes e benchmarks desenvolvidos inicialmente pela Intel, para facilitar a tarefa de verificar o resultado produzido.
No momento o desenvolvedor leva cerca de 15 minutos para compilar o kernel em seu notebook, e planeja ter completado em algumas semanas o desenvolvimento necessário para ter kernels Linux em qualidade de produção e completamente compilados com o Clang. (via lwn.net)
@brlinuxblog
Feed RSS
Te cuida GCC, os homi tão encostando!
uau! 15 minutos. Não li a materia original, mas algo abaixo deve ser verdade :
- o notebook dele é double-quad-quadcore.
- ele compilou bem pouca coisa do kernel
- esse compilador é f0d4.
:D
15 min.
Dependendo do que vc estiver compilando, o GCC faz em menos tempo. Agora se for o kernel do ubuntu, que tem quase tudo compilado como modulo, inclusive drivers para dispositivos que quase ninguém tem, ai sim da umas 2 horas compilando.
Já uso o clang para os meus projetos. E estou bastante satisfeito com os resultados desse compilador.
Espero que o clang fique cada vez melhor nos próximos anos e se torne um compilador à altura do gcc, senão melhor.
Ter softwares que não sejam presos à um compilador específico é sempre bom, pois ficar preso à uma solução, mesmo que seja de software livre, é muitas vezes igual a ficar preso a uma solução proprietária. Não é o caso do gcc, mas pode um dia ser dele ou de outros.
“Não é o caso do gcc, mas pode um dia ser dele ou de outros.”
OU NÃO.
Esse menino tenchi aprendeu bem. Fala tudo e não diz nada. Uma coisa linda de se ver. Ou não.
Quem sabe este nao seja o 1o passo para tirar qq dependencia de uma distro linux com gnu e Stallman parar de usar a popularidade dele como cabo eleitoral de campanha da fsf
@Rodrigo, GNU está profundamente enraizado no coração do Linux e milhares de outros softwares livres graças à GPL. Liberdade à qualquer custo foi a maior contribuição de Stallman, surpreendentemente maior até mesmo que emacs, que ainda não se tornou uma singularidade. Aliás, Stallman lembra bastante o Tiradentes até na aparência, menos rotundez…
A título de curiosidade, o ReactOS também está próximo de ser compilado integralmente pelo CLang. Atualmente ele só compila algumas partes. Hoje mesmo um dos desenvolvedores do ReactOS que mantém contato com o pessoal do CLang comentou que brevemente eles irão implementar uma das pendências que está impedindo uma compilação mais geral.
que lindo, uma implementação livre de compilador pela Apple sendo capaz de compilar uma implementação livre de SO da Microsoft… com sorte ReactOS também roda mono…
@Henrique: uma das metas do ReactOS é compilá-lo integralmente no Visual Studio (vá saber o porquê disso…).
@Tenchi
“pois ficar preso à uma solução, mesmo que seja de software livre, é muitas vezes igual a ficar preso a uma solução proprietária. ”
Não, não é igual, nem parecido. Talvez se depender do estilo de “Open Source” de alguns. Software Livre não, dá sempre chance para alternativas.
Não uso o clang nem o LLVM por padrão devido a licença e também por que não estou a procura de inovações descontroladas. O meu objetivo é a liberdade.
Tércio Martins (usuário não registrado) em 26/10/2010 às 3:29 pm:
“uma das metas do ReactOS é compilá-lo integralmente no Visual Studio (vá saber o porquê disso…).”
é para se certificar que é 100% dependente da Microsoft.
“uma implementação livre de compilador pela Apple”
A Apple colabora mas não é dona do projeto, que é livre, segundo a FSF.
@Tércio Martins
O principal motivo é poder utilizar os PDBs junto com o WinDBG o que aumentaria significativamente a efetividade de depuração de código.
Mesmo que o objetivo seja atingido, o projeto continuará a dar suporte aos dois compiladores (ou três quando o CLang virar realidade), que efetivamente se torna uma plataforma muito boa detectar bugs escondidos.
@ foobob
De fato, eu mesmo já consegui (literalmente com sorte) rodar o Mono no ReactOS), se quiser pode dar uma olhada em http://reactosbr.wordpress.com/2010/10/08/plataforma-net-no-reactos-com-o-mono/
Particularmente não me importo com o tempo demorado pra compilar, mas se o código gerado ficar mais rápido, largo o gcc sem dó nenhuma.
E vai ser bom pro GCC, um incentivo a mais pra continuar melhorando e rever velhos conceitos.
Vai ser ótimo para o GCC.
Sem competição, a inovação vira uma lesma.
Andre Luis Pereira
Engano seu .Não há necessidade de competir para produzir algo novo.Se alguém quer bricar com ferramentas de compilação que então faça um fork ou um novo projeto .Assim como a LLVM fez.A LLVM não está competindo com o GCC. Ela não quer matar o GCC,ao menos que alguns dos seus patrocinadores queiram isso.
Por favor pense um pouco .Tente desvincular inovação necessita competição.
O que não concordo com a LLVM é a licença e as intenções que eles querem com o projeto. Não quero ficar bricando com compiladores .Quero lutar pela liberdade.
@self_liar, mostre um exemplo onde a inovação não foi provocada pela competição? As vezes a competição não é explicita, mas desde que exista um produto que faça a mesma coisa, existe o sentimento de competição.
Victor
O software livre é um bom caso. A inovação é levada pela diferença de ideias e não um esforço de matar um projeto que existe. O povo do Xemacs não queria matar o Emacs .Eles somente não concordam o que o Emacs faz e então os desenvolvedores quiseram um emacs do jeito deles,que é o Xemacs.
Não sei se a competição é explicita ou implicita. Sei que existe tipos de competição .Esta competição que você fala até que saudavel ,ou seja, a competição que os participantes testam suas capacidades.
Agora a competição que se pratica tanto no sistema de trabalho quanto em muitos lugares ,se chama a competição destrutiva, ou seja,eu tenho que obrigatoriamente matar o outro para ter mais e/ou sobreviver.Essa é a competição terrível.
@Victor, a roda.
Acho que não houve muitos concorrentes para o cara que inventou a roda.
hauahauha
@Victor,
Já pensou se cada um que quisesse construir um sistema operacional alternativo não se juntassem para construir, por exemplo, o Linux? Não necessariamente inovação necessita de competição, precisa de motivação.
Ah tá, estavam competindo com o Windows; mas estavam cooperando entre si e não competindo.
Flávio Menezes
Isso mesmo .A competição não produz inovação .A competição produz motivação e a motivação PODE produzir inovação.
No sistema economico de hoje ,a competição destrutiva motiva os concorrentes a fazerem alguma coisa no mercado. Nem sempre é inovação .Uns optam por desviar impostos,corrupção no governo e poluição de rios . E outros optam em produzir alguma inovação.
O sistema de competição hoje é confundido com inovação porque quem vive em ameaça de morte faz de tudo para se manter vivo,inclusive destruir o resto do mundo para isso .Isso é tortura e uma forma dee produzir motivação (que PODE levar a inovação ) horrível.