Introdução ao GDB
GDB, o depurador do Projeto "GNU",
permite que você veja o que está acontecendo “dentro” de outro
aplicativo enquanto ele é executado - ou o que outro aplicativo
estava fazendo no momento em que travou. Observe que GDB é mais eficaz ao rastrear aplicativos e
bibliotecas que foram construídos(as) com símbolos de depuração e
não despojados(as).
Esse pacote é conhecido por construir e funcionar corretamente
usando uma plataforma LFS 12.2.
Informação do Pacote
-
Transferência (HTTP): https://ftp.gnu.org/gnu/gdb/gdb-15.1.tar.xz
-
Transferência (FTP):
-
Soma de verificação MD5 da transferência:
494e3beaac44e66367c3e443a4414529
-
Tamanho da transferência: 23 MB
-
Espaço em disco estimado exigido: 806 MB (adicionar 1,0 GB
para documentos; adicionar 720 MB para testes)
-
Tempo de construção estimado: 0,9 UPC (adicionar 0,4 UPC para
documentos; veja-se abaixo para testes; todos usando
paralelismo=8)
Dependências do GDB
Dependência Recomendada de Tempo de Execução
six-1.16.0 (módulo "Python" 3, exigido em tempo de
execução para usar scripts GDB a partir de vários pacotes do
LFS/BLFS com "Python" 3 instalado no LFS)
Opcionais
Doxygen-1.12.0, GCC-14.2.0 (ada, gfortran e go
são usados para testes), Guile-3.0.10, rustc-1.80.1 (usado para alguns testes),
Valgrind-3.23.0 e SystemTap (tempo de
execução, usado para testes)
Instalação do GDB
Instale o GDB executando os
seguintes comandos:
mkdir build &&
cd build &&
../configure --prefix=/usr \
--with-system-readline \
--with-python=/usr/bin/python3 &&
make
Opcionalmente, para construir a documentação da "API" usando
Doxygen-1.12.0, execute:
make -C gdb/doc doxy
Executar os testes não é recomendada. Os resultados variam muito
dependendo da arquitetura do sistema e de quais dependências
opcionais estão instaladas e qual versão do GCC está sendo usada.
Em um sistema testado, existiram 140 falhas inesperadas (de mais de
108.000 testes) e em outro sistema existiram “somente” 32 falhas
inesperadas. O tempo para executar os testes varia de
aproximadamente 6 UPC a mais de 15 UPC ao usar -j8. Isso depende do
número de testes que expiram, assim como de outros fatores.
Dica
Com um make check
simples, existem muitas mensagens de aviso acerca de um arquivo
de configuração global ausente. Essas podem ser evitadas
executando-se touch
global.exp e antepondo-se ao comando make check DEJAGNU=$PWD/global.exp. Além
disso, os testes podem ser consideravelmente acelerados usando-se
a opção do make
"-j<N>", onde <N> é o número de núcleos em teu
sistema.
Para testar os resultados de qualquer forma, emita:
pushd gdb/testsuite &&
make site.exp &&
echo "set gdb_test_timeout 30" >> site.exp &&
make check 2>1 | tee gdb-check.log
popd
Veja-se gdb/testsuite/README
e TestingGDB.
Existem muitos problemas adicionais com a suíte de teste:
-
Diretórios limpos são necessários se reexecutar-se os testes.
Por esse motivo, produza uma cópia do diretório do
código-fonte compilado antes dos testes, caso precise
executar os testes novamente.
-
Os resultados dependem dos compiladores instalados.
-
Em alguns sistemas baseados em "AMD", mais que duzentos (200)
testes adicionais possivelmente falhem devido a uma diferença
na implementação de camadas nessas "CPUs".
Agora, como o(a) usuário(a) root
:
make -C gdb install &&
make -C gdbserver install
Se você construiu a documentação da "API", [então] ela agora está
em "gdb/doc/doxy". Você consegue instalá-la (como o(a) usuário(a)
root
):
install -d /usr/share/doc/gdb-15.1 &&
rm -rf gdb/doc/doxy/xml &&
cp -Rv gdb/doc/doxy /usr/share/doc/gdb-15.1
Explicações do Comando
--with-system-readline
:
Essa chave força o GDB a usar a
cópia do Readline instalada no
LFS.
--with-python=/usr/bin/python3
: Essa
chave força GDB a usar Python 3.