Tenho que confessar minha ignorancia em relacao a macro assert(). Sempre encontrei ela em codigos GNU como testes para garantir a sanidade do programa, e achava um metodo simples mas com uma certa elegancia na depuracao. Eis que estou lendo a documentacao da versao de libc implementada pela newlib (biblioteca esta que estou pretendendo criar com o novo linker para fins de teste de funcionalidade no ArchC) e descubro que assert() na verdade e definida pela libc, ou seja, qualquer um pode usar livremente desde que inclua assert.h.assert() testa uma expressao logica, e caso ela seja falsa, o programa termina com uma chamada para abort() (de modo que um tratador de sinais SIGABRT possa capturar), depois de imprimir "Assertion failed: expression, file filename, line lineno". O cumulo da elegancia, nao? O usuario que ver uma mensagem dessas vai pensar "meu deus, que programa bem feito!". Ok, pode nao ser, mas e melhor do que isso:if (vetor == NULL) printf("droga!");else printf("ufa");Ainda mais por poder ser substituido por apenas isso:assert(vetor != NULL);Nem preciso dizer que vou inundar meu codigo de asserts. Para breve pretendo fazer um programa auxiliar para o ArchC que le informacoes de depuracao DWARF em um binario ELF e traduz endereco para linha de codigo C. Tambem penso em disponibilizar esta funcionalidade como uma funcao de auxilio para quem cria modelos para o ArchC (imprimir um erro informando a linha de codigo C que causou, e nao o endereco).Estou anotando aqui para nao esquecer deste projeto, pois ja andei dando uma lida na documentacao do DWARF e vi que e viavel. Ha poucos dias disse que tinha ligado a newlib para ARM, e alterado seu arquivo syscalls.c para obedecer as chamadas de syscalls do ArchC, e que consegui com que a syscall exit funcionasse (finalizando o programa). Tentei um printf("Hello World!"), mas nao funcionou, como havia dito.Depois de ficar bastante tempo depurando o comportamento de cada instrucao, da primeira chamada de printf() ate chegar a syscall write(), com muita sorte e atencao finalmente percebi o que estava de errado no modelo do ARM, e tratava-se de um bug muito sutil, que so ocorria na instrucao LDR (load word) quando o acesso a memoria nao estava alinhado em 32-bit.Agora ja compilei o programa blowfish (criptografia), do benchmark Mibench, e rodando "bftest", seu programa de testes, obtemos nao so a confirmacao de que um printf() esta funcionando, mas que todo o programa de criptografia esta funcional:rafael@manber-virt:~/Projetos/armv5$ ./armv5e.x --load=/home/rafael/actest/tests/blowfish/bftest SystemC 2.2.0 --- Dec 10 2008 14:08:13 Copyright (c) 1996-2006 by all Contributors ALL RIGHTS RESERVEDArchC: Reading ELF application file: /home/rafael/actest/tests/blowfish/bftestArchC: -------------------- Starting Simulation --------------------Info: (I804) /IEEE_Std_1666/deprecated: sc_start(double) deprecated, use sc_start(sc_time) or sc_start()testing blowfish in raw ecb modeSet key.Encrypted.decrypted.Set key.Encrypted.decrypted.testing blowfish in ecb modetesting blowfish set_keytesting blowfish in cbc modetesting blowfish in cfb64 modetesting blowfish in ofb64ArchC: -------------------- Simulation Finished --------------------SystemC: simulation stopped by user.ArchC: Simulation statistics Times: 5.78 user, 0.13 system, 5.89 real Number of instructions executed: 11061127 Simulation speed: 1913.69 K instr/sInfo: (I804) /IEEE_Std_1666/deprecated: You can turn off warnings about IEEE 1666 deprecated features by placing this method call as the first statement