Introduction à GDB
GDB, le débogueur du projet GNU,
permet de voir ce qu'il se passe « à
l'intérieur » d'un autre programme, pendant
qu'il s'exécute — ou ce que faisait un autre programme au
moment où il a planté. Notez que GDB est plus performant quand les programmes
et les bibliothèques tracées sont construits avec les symboles de
débogage et qu'ils n'ont pas été nettoyés.
Ce paquet est connu pour pouvoir être construit et fonctionner
correctement avec une plateform 12.2.
Informations sur le paquet
-
Téléchargement (HTTP) : https://ftp.gnu.org/gnu/gdb/gdb-15.1.tar.xz
-
Téléchargement (FTP) :
-
Somme de contrôle MD5 du téléchargement :
494e3beaac44e66367c3e443a4414529
-
Taille du téléchargement : 23 Mo
-
Estimation de l'espace disque requis : 806 Mo (plus
1,0 Go pour la doc, plus 720 Mo pour les tests)
-
Estimation du temps de construction : 0,9 SBU (plus
0,4 SBU pour la doc, voir plus bas pour les tests, le
tout avec parallélisme = 8)
Dépendances de GDB
Dépendance recommandée à l'exécution
six-1.16.0 (module Python 3, requis à l'exécution
pour utiliser des scripts GDB de divers paquets de LFS et BLFS avec
le Python 3 installé dans LFS)
Facultatives
Doxygen-1.12.0, GCC-14.2.0 (ada, gfortran et go
sont utilisés pour certains tests), Guile-3.0.10, rustc-1.80.1 (utilisé par
certains tests), Valgrind-3.23.0 et SystemTap (dépendance
d'exécution, utilisé pour les tests)
Installation de GDB
Installez GDB en exécutant les
commandes suivantes :
mkdir build &&
cd build &&
../configure --prefix=/usr \
--with-system-readline \
--with-python=/usr/bin/python3 &&
make
Éventuellement, pour construire la documentation de l'API en
utilisant Doxygen-1.12.0, lancez :
make -C gdb/doc doxy
Il n'est pas recommandé d'exécuter les tests. Les résultats varient
beaucoup en fonction de l'architecture du système et des
dépendances facultatives installées et la version de gcc utilisée.
Sur un système testé, il y a eu 140 échecs imprévus (sur plus de
108 000 tests) et sur un autre système « seulement »
32 échecs imprévus. La durée d'exécution des tests varie entre
environ 6 SBU à plus de 15 SBU avec -j8. Cela dépend du
nombre de tests qui dépassent leur délai d'attente et d'autres
facteurs.
![[Astuce]](../images/tip.png)
Astuce
Avec un simple make
check, il y a de nombreux messages
d'avertissement à propos d'un fichier de configuration global
manquant. On peut les éviter en exécutant touch global.exp et en ajoutant
avant la commande make
check, DEJAGNU=$PWD/global.exp. De
plus, les tests peuvent être considérablement accélérés en
utilisant l'option make « -j<N> »
où <N> est le nombre de cœurs sur votre système.
Pour tout de même tester les résultats exécutez :
pushd gdb/testsuite &&
make site.exp &&
echo "set gdb_test_timeout 30" >> site.exp &&
make check 2>1 | tee gdb-check.log
popd
Voir gdb/testsuite/README et
TestingGDB. Il y a
plein de problèmes supplémentaires avec la suite de tests :
-
Des répertoires propres sont requis si vous relancez les
tests. Pour cette raison, il est recommandé de créer une
copie du répertoire des codes sources compilés avant les
tests au cas où vous devriez relancer les tests.
-
Les résultats dépendent des compilateurs installés.
-
Sur certains systèmes AMD, plus de 200 tests supplémentaires
ont échoués à cause d'une différence dans l'implémentation du
parallélisme sur ces CPU.
Maintenant, en tant qu'utilisateur root :
make -C gdb install &&
make -C gdbserver install
Si vous avez construit la documentation de l'API, c'est maintenant
dans gdb/doc/doxy. Vous pouvez l'installer (en tant qu'utilisateur
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
Explication des commandes
--with-system-readline : Ce
paramètre force GDB a utiliser la
copie de Readline installée dans
LFS.
--with-python=/usr/bin/python3 :
ce paramètre force GDB à utiliser
Python 3.