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

return void();

É uma pequeneza mas eu gostaria muito que as linguagens da família do C permitissem retornar void quando a função retorna void . Escrever da forma a seguir me aborrece. public class Foo  {    public void log (String msg) { }    public void bar (String x, String y) { }    public void bar (String x)    {      if (x == null)      {        log("x was null");        return;      }      bar(x, "default");    } } Eu ficaria mais feliz escrevendo assim: public class Foo  {    public void log (String msg) { }    public void bar (String x, String y) { }    public void bar (String x)    {      if (x == null) return log("x was null");      bar(x, "default");     } }
Postar um comentário
Leia mais

.NET COM Interop, IStream e Visual Studio

Investigando oportunidades para otimizar um componente, experimentei definir métodos que não solicitam dados (em arrays etc.) como argumentos mas sim instâncias de IStream , e me deparei com um problema interessante: interoperabilidade com .NET. Usar componentes COM em programas .NET não é particularmente difícil; no Visual Studio, é possível adicionar componentes COM como referências no projeto. Se o componente for capaz de Automation, é possível usar a ferramenta tlbimp.exe para gerar manualmente um callable wrapper para o componente, que, se eu entendi as coisas corretamente, não precisa ser distribuído com a aplicação. Porém, todos os métodos que eu aprendi tem essa peculiaridade: eles parecem assumir que um componente não usa interfaces definidas por outros componentes -- como, por exemplo, declarando parâmetros com tipo IStream , uma interface definida pelo sistema. Pelo método do callable wrapper , a ferramenta assume que as interfaces mencionadas integram o componente...
Postar um comentário
Leia mais

Eclipse PDE com Gradle

Na virada de 2016 para 2017, adotamos oficialmente o Gradle como ferramenta de construção de software na Prodist. A fila da migração está fluindo confortavelmente desde então. Já temos as provas de conceito necessárias para todos os projetos, inclusive os projetos nativos para compilador C++. Para fontes Java usamos Eclipse. Integramos projetos Gradle ao Eclipse usando Buildship . Acho que o Buildship ainda tem um longo caminho pela frente, mas realiza tudo o que necessitamos. Já estamos entregando com base nesse esquema. O problema mais importante que encontramos foi na integração de projetos OSGi. No Eclipse, trabalhamos projetos OSGi com o PDE. Nosso ciclo de desenvolvimento inclui rodar configurações "OSGi Framework" no Eclipse para teste. Infelizmente, o PDE assume uma estrutura de projeto própria e não funciona corretamente caso contrário. Estes problemas estão registrados em bugs como, por exemplo, o  bug 153023 . Nossos projetos OSGi com Gradle usam o layout ...
Postar um comentário
Leia mais