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.3.
Informação do Pacote
-
Transferência (HTTP): https://ftp.gnu.org/gnu/gdb/gdb-16.2.tar.xz
-
Transferência (FTP):
-
Soma de verificação MD5 da transferência:
05e4a7e3b177432771aa7277af9bccee
-
Tamanho da transferência: 23 MB
-
Espaço em disco estimado exigido: 1,0 GB (adicionar 943 MB
para documentos; adicionar 960 MB para testes)
-
Tempo de construção estimado: 1,4 UPC (adicionar 0,3 UPC para
documentos; adicionar 3,0 UPC testes; todos usando
paralelismo=8)
Dependências do GDB
Dependência Recomendada de Tempo de Execução
six-1.17.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.13.2, GCC-14.2.0 (ada, gfortran e go
são usados para testes), Guile-3.0.10, rustc-1.85.0 (usado para alguns testes),
Valgrind-3.24.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.13.2, execute:
make -C gdb/doc doxy
Executar os testes não é recomendado. 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” 14 falhas
inesperadas. O tempo para executar os testes varia de
aproximadamente 3 UPC a mais de 15 UPC ao usar -j8. Isso depende do
número de testes que expiram, assim como de outros fatores.
![[Dica]](../images/tip.png)
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. Às vezes, porém, usar paralelismo possivelmente resulte
em falhas estranhas.
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 também podem depender 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".
-
Para gdb-16.1, usando um Intel Xeon E5-1650 v3, existiram 14
falhas inesperadas em mais de 120.000 testes.
-
Quatro testes na suíte gdb.base/step-over-syscall.exp são
conhecidos por falharem devido a mudanças no Linux 6.13 e
glibc-2.41.
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-16.2 &&
rm -rf gdb/doc/doxy/xml &&
cp -Rv gdb/doc/doxy /usr/share/doc/gdb-16.2
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.