Em programação, como as vezes não temos como saber onde pode estar aquele erro maldito, um bom depurador pode ser o nosso melhor amigo. Nesse artigo falarei de breakpoints: o que são, como definí-los, porque utilizá-los e também outros comandos como o list, next, run e o print.
Se você não gosta de passar o arquivo que o gdb tratará
pela linha de comando, pode fazer isso através do comando
"file" seguido de um espaço e do nome do arquivo (não
esquecer o enter :p).
(gdb) file ex
Reading symbols from ex...done.
Percebam que quando estamos no gdb o prompt se torna "(gdb)".
Aqui o programa não contem erros, mas foi compilado com a opção
"-g" no gcc. Assim, ele conseguiu ler corretamente o arquivo.
O comando para executar o programa é o "run", onde
qualquer parâmetro que seja dado para ele será considerado do
programa que será executado.
(gdb) run
Starting program: /home/rlucca/C/seila/ex
01! 02! 03! 04! 05!
Program exited normally.
(gdb) file /bin/ls
Load new symbol table from "/bin/ls"? (y or n) y
Reading symbols from /bin/ls...
(no debugging symbols found)...done.
Bem, quem for analisar o exemplo acima pelo já comentado verá
que executamos um programa chamado "ex", que foi carregado
anteriormente com "file". Assim, a saída "01! 02! 03! 04! 05!"
é do programa que tem a única função de ser exemplo para a
execução daqui e conta de 1 até 5 exibindo sempre 2 casas.
Mas e depois? Temos mais 1 exemplo do uso de "file" para carregar
programas. Quando já temos um arquivo carregado o gdb nos pergunta
se queremos realmente reler os "dados" novamente. Respondendo "yes"
(sim, em Português), ele tentará ler os dados. Mas, o que é isso?
Nenhum símbolo foi encontrado pro depurador poder usar. Sim, é
isso mesmo! Isso é um exemplo do que ocorre quando tentamos
carregar um executável compilado sem informações pro depurador.
[1] Comentário enviado por jose_maria em 20/05/2004 - 10:53h
Parabéns pelo artigo. Eu estava realmente procurando informações de como usar o gdb.
Mas eu fiquei com algumas dúvidas:
- Eu não consegui executar o comando ctrl+pipe, simplesmente não aconteceu nada. Eu também não entendi para que serve o comando.
- O comando list não funcionou no meu gdb, fica assim:
(gdb) list
1 ../sysdeps/i386/elf/start.S: No such file or directory.
in ../sysdeps/i386/elf/start.S
[2] Comentário enviado por jllucca em 20/05/2004 - 20:54h
CTRL+PIPE é usado para interromper o programa e gerar um arquivo core. Se o arquivo não for criado experimente fazer um "ulimit -c 99000" porque normalmente o pessoal gosta de deixar o limite dos arquivos cores para "0"(Zero) o que impossibilita a criação deles.
Quanto ao problema com o gdb estou com um igual na faculdade. Mas, quando descobrir como resolver posto aqui. A primeira coisa normalmente que agente vê se esta "OK" é vermos se compilamos os programas usando a flag "-g". To me sentido muito mal por não ter como usar o gdb, o jeito é fazer testes...
Sem erros, enquanto que:
$ make clean
$ make all
$ gdb promname
(gdb) list
1 ../sysdeps/i386/elf/start.S: No such file or directory.
in ../sysdeps/i386/elf/start.S
Assim, estou tentando dinovo organizar o meu Makefile porque eh ele o gerador de caso. Quanto ao seu programa se quiser conversar por email fica muito melhor!
[4] Comentário enviado por engos em 25/06/2004 - 11:42h
Legal o artigo, mas você não o encerrou muito cedo?
Acho que ficou faltando comentar que não é necessário ser um arquivo de core para debugar o programa, sem contar que poderia ter sido colocado mais de um breakpoint ou como remover os breakpoints.
Ficou bem redigido e de fácil entendimento, aconselho a postar um artigo complementar que explore mais o gdb, principalmente outras opções, qualquer coisa posso ajudar.
[5] Comentário enviado por jllucca em 27/07/2004 - 00:24h
Opa,
sobre o artigo ter acabado meio cedo. Realmente, estou pensando em escrever uma segunda parte. Mas, nada muito apressada que nem a segunda parte do void que como voce mesmo disse e depois eu fui ver realmente passa uma impressão meio vaga.
[6] Comentário enviado por wildtux em 16/01/2014 - 12:13h
Estou usando o gdb tanto no Linux quanto no cygwin. Muito bom o artigo. Já vi a parte 2 também, ficou realmente mais esclarecedora que a primeira, claro sem desmerecer a primeira. Boa iniciativa parabéns.