Pular para o conteúdo principal

Construindo um "cross toolchain" com GCC 5.1 e binutils 2.25

Uma das Pesquisas no Laboratório investiga o uso de C++ moderno (inicialmente 2011, agora 2014) na definição de programas bare metal. Nosso interesse geral está em aplicações de I/O e um dos nossos interesses específicos está em aplicações tipo "dispositivo criptográfico".

Ao retornar para esta Pesquisa, resolvemos atualizar nossas ferramentas para obter uma implementação completa do C++ 2014. Nossa motivação foi o lançamento do GCC 5.1 que inclui suporte completo para esta nova especificação.

Nosso objetivo é estudar aplicações para BIOS, UEFI, Multiboot 1 e 2 e outras "máquinas" similares emuladas com qemu. Estamos construindo programas para arquitetura i686-pc-elf. Nosso ambiente de desenvolvimento é Fedora 21 64 bits, onde as ferramentas tem arquitura alvo x86_64-redhat-linux. Apesar de x86_64 e i686 serem "compatíveis", nesse tipo de projeto é necessário um cross toolchain.

Precisamos basicamente de um cross binutils e um cross g++. Existem diversas maneiras de obter o toolchain final, esta é a maneira que funcionou para nós.

Para construir binutils, explodimos o pacote de código-fonte, configuramos com o --target i686-pc-elf e o --prefix onde será instalado o nosso novo toolchain, e usamos make normalmente.

  • tar -xzf binutils-2.25.tar.gz
  • mkdir binutils-i686-pc-elf
  • pushd binutils-i686-pc-elf
  • ../binutils-2.25/configure --build=x86_64-redhat-linux --target=i686-pc-elf --prefix=/opt/tools-i686-pc-elf
  • make
  • popd

Para construir gcc, explodimos o pacote de código-fonte e configuramos de acordo com binutils, então usamos make com certos make target especiais para construir aquilo que faz sentido.
  • tar -xjf gcc-5.1.0.tar.bz2
  • mkdir gcc-i686-pc-elf
  • pushd gcc-i686-pc-elf
  • ../gcc-5.1.0/configure --build=x86_64-redhat-linux --target=i686-pc-elf --prefix=/opt/tools-i686-pc-elf --enable-languages=c,c++ --without-headers
  • make all-gcc
  • make all-target-libgcc
  • make install-gcc
  • make install-target-libgcc
  • popd
Com este cross toolchain conseguimos construir programas para rodar no qemu com depuração no gdb.
Marcadores:

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Análise vs. Projeto

Eu diria que a ruptura entre Análise e o Projeto acontece quando acabam as considerações sobre o problema e começam as considerações sobre a solução. Em outras palavras, o papel do Analista é considerar o problema, enquanto o papel do Projetista é o de considerar a solução. Assim, o Analista aparece quando um problema aparece, e dá lugar ao Projetista quando o problema foi devidamente analisado, restando produzir para ele uma solução. E diria que a ruptura entre a Especificação e a Implementação acontece quando acabam os artefatos para consumo por humanos e começam os artefatos para consumo por máquinas. Em outras palavras, o papel do Especificador é produzir artefatos para consumo por humanos, enquanto o papel do Implementador é produzir artefatos para consumo por máquinas. Assim, o Especificador aparece quando a atividade é produzir efeitos sobre humanos, e dá lugar ao Implementador quando os humanos estão devidamente satisfeitos e a atividade prossegue para produzir efeito...
Postar um comentário
Leia mais

Por que goto é considerado prejudicial?

Recentemente, o Fabiano Vasconcelos abriu uma discussão no Grupo de Usuários de C e C++: De cara eu vi algo aqui um pouco estranho, se que o amigo Márcio me permite comentar: que muitos programadores, inclusive eu (se que posso ser rotulado como programador) foram instruídos com o princípio de NUNCA usar o goto, por ser considerado um mau estilo de programação. Durante a discussão, o Eduardo Vieira puxou um artigo da KernelTrap sobre uma discussão similar ocorrida no grupo de desenvolvimento do Linux, onde Robert Wilken disse o seguinte: In general, if you can structure your code properly, you should never need a goto, and if you don't need a goto you shouldn't use it. It's just "common sense" as I've always been taught. Unless you're intentionally trying to write code that's harder for others to read. É preciso colocar a máxima "goto considered harmful" na perspectiva histórica adequada. Acredito que praticamente todo programador trein...
Postar um comentário
Leia mais

Servidor e usuário COM na mesma "solution"

 Um dos objetivos da próxima iteração no meu projeto atual é quebrar o sistema em mais pedaços, e levantar os pedaços um nível de abstração até componentes COM. Uma das consequências é substituir diversas ligações mais estáticas e torná-las ligações mais dinâmicas através do COM. Tipicamente, um programa usuário de um componente COM, escrito para o Visual Studio, usará a diretiva #import para incluir na unidade de tradução C++ as declarações necessárias. Isso implica que o componente deve estar instalado na máquina que constrói o programa. O que fazer quando o componente em questão está no mesmo lote de construção que o programa usuário? A solução inicial é criar uma dependência de construção tal que o componente seja sempre construído primeiro, e usar um post-build event ao projeto do componente para registrá-lo no sistema. Desse modo, na construção do programa, o ambiente estará correto. Eu considero este arranjo prejudicial. Minha melhor razão é esta: o servidor de const...
Postar um comentário
Leia mais