- Tablegen backend for ArchC? Como fazer binarios ARM ligados a newlib funcionar no simulador do ArchC? Durante algum tempo enfrentei esse problema e encarei a responsabilidade de provar que o modelo do ARM estava funcional. Como corrigi alguns erros nesse modelo e acreditei que ele estava funcional, queria por isto a prova. E claro que para mostrar isso, e necessario que as funcoes basicas da libc estejam funcionando para que possamos compilar programas de benchmark (a implementacao da libc que usamos para validar modelos do ArchC e a newlib).A minha primeira abordagem, publicada em um post passado, foi a de fazer o port da newlib para as syscalls do ArchC personalizadas para o ARM. No ArchC, as syscalls atendem em enderecos fixos, em uma faixa reservada (0x0-0x100)*. Alterei o arquivo que define as syscalls para o ARM com codigo em linguagem de montagem ARM para efetivamente realizar um branch para o endereco da syscall adequada. Esta abordagem foi um sucesso parcial, pois algumas funcoes nao estavam em completa funcionalidade, sem contar que era necessario alterar diretamente o codigo da newlib. Portanto, esta solucao era claramente temporaria e com carater de testes. Nao poderia recomenda-la sempre que alguem precisasse compilar programas para ARM voltados para execucao no simulador ArchC-ARM.Para o proposito de redirecionar a newlib para usar este modo de syscalls peculiar utilizado no simulador do ArchC, existe uma biblioteca especifica disponivel no ArchC, libac_sysc.a, e um arquivo "specs" para o gcc, ac_specs, que redefine como o ligador deve montar o binario (ja prepara para respeitar a faixa reservada) e como ligar as bibliotecas basicas (no caso a libc.a e libac_sysc.a sao usadas em conjunto para que tudo funcione). Na arvore do codigo-fonte do ArchC, tais artefatos se encontram em "src/aclib/ac_syscall/libac_sysc". La existe um makefile que deve ser usado de modo a informar a arquitetura alvo (exemplo "make TARGET=arm-elf" - neste caso o cross-compiler "arm-elf-gcc" e usado para compilar a biblioteca, pois este pedaco de codigo sera anexado a todo programa ARM que voce compilar). Depois de construida, a biblioteca ficara disponivel na mesma pasta, e e sua responsabilidade copia-la (arquivo libac_syc.a) para a pasta "lib" de seu cross-compiler "raiz_do_compilador/arm-elf/lib", bem como o arquivo ac_specs. Crie tambem o arquivo ac_start.o incluido no inicio de todo programa, para substituir o classico crt0.o (que e fornecido pela newlib). O ac_start pode ser facilmente produzido com um codigo que executa um branch para o simbolo "main" e em seguida outro branch para o simbolo "exit" (deve ser feito direto em linguagem de montagem e produzido com o montador "arm-elf-as ac_start.s -o ac_start.o").Entretanto, a abordagem do ArchC (utilizando a libac_sysc) estava falhando para o caso do ARM. Apos algum tempo de investigacao e com a ajuda de colegas do LSC, descobrimos que a newlib apresenta uma configuracao singular para o caso do ARM (e de poucos outros alvos). As syscalls, que normalmente estavam definidas na libgloss (que pode ser facilmente substituida pela libac_sysc), estavam sendo definidas diretamente na libc. Desse modo era impossivel que a libac_sysc entrasse em acao. Ainda, o codigo da biblioteca libac_sysc nao