Some list of items to take into consideration for ArchC's future.How hard would be to:- Create a complete documentation of ArchC's current internals?- Create an Eclipse plug-in to make this IDE to understand ArchC's models? No post passado, disse que era extremamente dificil depurar um codigo compilado em C e que roda no simulador do ArchC. Mas como e possivel depurar, se o codigo que roda no simulador e em linguagem de montagem, e o simulador nao ira ler informacoes de debug e sair imprimindo as linhas do codigo C? Se tivermos o endereco da instrucao, podemos facilmente obter em que linha de codigo C o programa esta. Essa conversao "endereco da instrucao" -> "linha de codigo" e muito util tambem quando qualquer programa imprime um erro fatal e finaliza dizendo apenas o endereco com a instrucao ofensiva, ou imprime um "backtrace" (olhando na pilha os enderecos de retorno e portanto oferecendo um historico de como chegamos ate a funcao atual onde o erro ocorre) com diversos enderecos na pilha, mas sem informacao de qual linha de codigo estao as chamadas de funcao. Isto ocorre, por exemplo, quando voce compila um programa com a flag -D_FORTIFY_SOURCE=2 (nos gcc atuais isso e o padrao quando usado -O2). Esta flag liga um verificador de buffer overflow. Quando voce escreve em um campo de uma estrutura e ultrapassa seu tamanho (geralmente com uma funcao de copia de string), por exemplo, o programa e encerrado com estes amigaveis dizeres:overflow detected ***: ./programa terminated ======= Backtrace: ========= /lib/libc.so.6(__fortify_fail+0x48)[0x22b6f8] /lib/libc.so.6[0x229810] /lib/libc.so.6[0x228f08] /lib/libc.so.6(_IO_default_xsputn+0xc8)[0x19f608] /lib/libc.so.6(__printf_fp+0x14c2)[0x177d92] /lib/libc.so.6(_IO_vfprintf+0x3ca)[0x171a0a] /lib/libc.so.6(__vsprintf_chk+0xa7)[0x228fb7] /lib/libc.so.6(__sprintf_chk+0x2d)[0x228efd] ./programa[0x8048db7]No caso, se olharmos o backtrace, percebemos que quem chamou o sprintf() com um buffer pequeno (que sofreu overflow) foi uma funcao dentro de "./programa", endereco 0x8048db7. Bom, isso aparentemente nao diz nada. Nestes casos, se tivermos o programa compilado com simbolos de debug, uma opcao e usar o objdump. readelf e objdump sao programas correlatos que extraem informacoes de arquivos objeto ELF (executaveis, relocaveis ou dinamicos). readelf e uma versao que nao usa a libbfd, e com uma formatacao muito melhor. Entretanto, para disassembly, o objdump deve ser usado, pois so ele oferece essa opcao. Assim, usamos o parametro "-S" denominado "intermix source and assembly". Esta opcao ira nao so realizar o disassembly, mas tambem ira imprimir as linhas correlatas do codigo quando informacoes de debug DWARF estiverem disponiveis no arquivo objeto (ou seja, quando voce compilou com gcc -g e nao usou a infeliz opcao -strip em um ligador, que ocasionaria a remocao destas informacoes).objdump -S ./programa &> logA saida produzida geralmente e bem extensa (pois imprime todo o codigo e todas as instrucoes), por isso costumo salvar em um arquivo separado. Voce pode alternativamente usar qualquer outro metodo mais sofisticado para tratar a saida e encontrar o endereco que queremos. Analisando o arquivo log, onde salvei a saida, encontraremos algo como:struct buf { char campo[10];} buffer;sprintf(buffer.campo, "1234567890"); ... 8048db7: ea000019 b 0x44c ; sprintfOu seja, o objdump mistura as linhas do codigo C com as instrucoes relacionadas e o mais importante e que sempre fornece o endereco das instrucoes.Agora