Gdb reloaded

Acho que encontrei um estímulo a mais para usar o gdb com frequência.

Outro dia comentei com o Fred (e enchi o saco dele com os meus screenshots) sobre o uso do emacs como front-end do gdb. É ótimo. Basta dar um M-x gdb e ele aparece bem do lado, se você tiver com duas views na tela. Caso não esteja, C-x 3, resolve.

Brinquei um pouco, achei interessante, mas aquela montoeira de etapas para se depurar me remeteram o meu velho assert ou mesmo usar puts e printf‘s bem colocados. Sim, meus programas são bem simples e isto me basta. Para que ficar carregando o gdb? Gdb, só quando a coisa fica muito feia.

Na realidade, escondo a minha preguiça em carregar os breakpoints e ao sair perdê-los… Sei que deve haver um jeito de fazer isto persistir entre sessões, mas sinceramente, estou usando o meu tempo para aprender `C’, mais e mais. (:-).

Hoje deparei com a dica sobre um truque interessante, visto na DDJ (sim a sempre querida DDJ!): Como colocar os breakpoints diretamente no seu código fonte!

Muito interessante e ainda de quebra achei utilidade prática, i.e. não somente para otimizar ou estilizar, para a técnica que o Fred sempre usa – asm inline.

O que o gdb precisa é de uma interrupção e ele para ali. Testei inicialmente o comando "embutido".

#define EMBED_BREAKPOINT asm volatile ("int3;")

E insere-se a macro no local de parada. Voilá ! Daí basta rodar o gdb e parar naquele ponto.

Bom… Mas nem tanto. Pois o gdb tem necessidades mais complexas. Afinal isto não é um breakpoint de fato, mas uma "parada brusca", aliás uma interrupção, na realidade uma TRAP, prevista no set de instruções do processador para efetuar estas paradas no código. Veja uma explicação melhor aqui.

Então, depois de indicado pela nossa leitura ao DDJ, cheguei neste blog, cujo nome é muito criativo: main is usually a function, o qual entendi que seja uma apologia declarada ao `C’. Lá é onde podemos ver a aplicação do recurso apresentado, só que em melhor estilo.

#define EMBED_BREAKPOINT                  \
    asm("0:"                              \
        ".pushsection embed-breakpoints;" \
        ".quad 0b;"                       \
        ".popsection;")

O que se faz neste hack é colocar labels nos pontos estratégicos para que o gdb os utilize ao rodar.

Vou poupá-los de códigos de demonstração, afinal eles estão no artigo original, no site do autor, os mesmo podem ser vistos e podem ser baixados via github.

Notas adicionais para que for compilar os exemplos apontados:

  • Instale o binutils-dev, o cabeçalho bfd.h – da library binary file descriptors – encontra-se lá.
  • Desnecessário dizer, mas não se esqueça de incluir -lbfd na linha de compilação.
  • Se for usar, como eu, o -std=c89, as declarações no interior dos `for’ devem ser retrabalhadas.
  • Há uma warning sobre redefinição do snprintf que não impede o funcionamento, entretanto, se usar -Werror, deve-se “pragmatizar”.
  • Se for usar o wrapper, melhor torná-lo acessível via /etc/alternatives (Debian, no meu caso):
  • # update-alternatives --install /usr/bin/dbg dbg /usr/local/bin/gdb-with-breakpoints 50
    
  • E, no caso do emacs, melhor customizar o GUD (Grand Unified Debugger).

No mais, o gdb-with-breakpoints funcionou bem aqui.

Continuar lendo

Git – “também” uma ferramenta de desenvolvimento

Meus estudos sobre o Git

Os arquivos aqui existentes e nos links indicados são ótimos para concentrar as informações e estudos sobre esta ferramenta que entendo como indispensável para se produzir, controlar, documentar, avaliar códigos-fontes e medir a evolução de um projeto. Seja ele “em equipe” ou “solo”.

As adições de novas fontes de informação e áreas de testes como repositórios de ensaios devem ser mantidas num local e este local deveria ser administrado da forma mais simples e eficiente possível. Acho que foi pensando numa ferramenta assim que o Sr. Torvalds dedicou-se a criar o git e deu uma atenção “visceral” à ela.

O que é o Git ?

Git é uma ferramenta de controle e gerenciamento e código-fonte de projetos que pode ser utilizada localmente, i.e sem necessidade de um repositório central como nos tradicionais CVS’s, e passível de existir em qualquer canto – como num pedrive ou dvd.
Vocẽ pode levar para qualquer lugar e gerar cópias em qualquer parte, sem perder o histórico de seus trabalhos, tendo-os sempre á mão em qualquer plataforma. Sim, é portátil e portável.

Em míudos, o git pode ser visto como um banco de dados muito versátil e de fácil acesso, onde os dados deste banco é qualquer coisa – em termos de documentos digitais – que se queira manter controle.

O preço?

O mesmo que se paga por qualquer software livre: o seu tempo investido em “dominar com maestria” a sua operação e o contexto onde se aplica.

Continuar lendo

O código e a história

Há um dilema que me atormenta: manter o histórico de um projeto para que, quando se está trabalhando sozinho? Vale a pena o esforço?

Eu tentei utilizar várias ferramentas: cvs, subversion, bazar e o git. Todas são bem interessantes no início, mas se tornam bem “chatinhas” depois de uma ou duas semanas. Parecem pedras no caminho. Temos que ficar parando e documentando, analisando código velho e ainda por cima borrando idéias novas.

Mas nunca perdi a vontade de manter o histórico evolutivo de um projeto e, mesmo sem muita habilidade, venho fazendo isto.

Recentemente recuperei e “reprisei” a evolução de um projeto do qual havia feito o “breadcrumb” por um mês. Note aqui que o meu “breadcrumb” é o de alterações no projeto, não a técnica utilizada para navegação em sites.

Foi uma experiência interessante pois retomei um projeto do zero, iniciado em nov/2008 e concluído em dez/2008. Foi como ver um filme antigo antes de tentar reescrever uma nova etapa. Mas o que me deixou chateado foi que eu já havia usado várias ferramentas antes do bazar, que estava no controle daquele final de projeto (eu ainda não havia usado o git).

Tentei por todo o jeito importar diretamente do bazar para o git mas sem sucesso. Daí parti para rever o código usando o bzr mesmo. Depois de umas três horas testando recolocando e analisando os resultados com o bzr diff, “reaprendi” como eu tinha feito o projeto que estava meio apagado da minha memória, após alguns anos. Em seguida percebi que o curto período avaliado registraram grandes modificações no meu modo de pensar – em questão de dois meses, muda-se muito de idéia. Mas restava a frustração de não ter o histórico completo.

Há pouco, baixei o repositório do kernel do linux e pensei: como era a versão 0.0.1 do sistema? Será que vou ver o “initial import” do linux? Legal!

Mandei um git log > /tmp/log e fui avaliar !

Eis a minha surpresa:

4002798 commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
4002799 Author: Linus Torvalds <torvalds@ppc970.osdl.org>
4002800 Date:   Sat Apr 16 15:20:36 2005 -0700
4002801
4002802     Linux-2.6.12-rc2
4002803
4002804     Initial git repository build. I'm not bothering with the full history,
4002805     even though we have it. We can create a separate "historical" git
4002806     archive of that later if we want to, and in the meantime it's about
4002807     3.2GB when imported into git - space that would just make the early
4002808     git days unnecessarily complicated, when we don't have a lot of good
4002809     infrastructure for it.
4002810
4002811     Let it rip!

Pelo jeito, o problema de se perder o histórico aconteceu inclusive com o autor do linux e do git.

Independente da minha frustração, fiquei satisfeito por ver que o “modo” de pensar, em termos de controle de versões, é problemático também por quem tem muita habilidade.

Repasso, então, a lição aprendida: priorize o resultado e faça a história depois. Mas faça, o código e a história!