<HTML>
<HEAD>
<TITLE>Déboguer et optimiser</TITLE>
</HEAD>
<BODY>
<H1>5. <A NAME="s5"></A>Déboguer et optimiser</H1>
<P>
<A HREF="GCC-HOWTO.html#toc5">Contenu de cette section</A></P>
<A NAME="index.58"></A> <H2>5.1 <A NAME="ss5.1"></A> Etude préventive du code (lint) </H2>
<P> Il n'existe pas de lint qui soit réellement utilisable, tout simplement
parce que la grande majorité des développeurs sont satisfaits des messages
d'avertissement de gcc. Il est probable que l'option la plus utile est
l'option <CODE>-Wall</CODE> --- qui a pour effet d'afficher tous les
avertissements possibles.</P>
<P>Il existe une version du domaine public du programme lint
que vous pouvez trouver à l'adresse suivante :
<A HREF="ftp://larch.lcs.mit.edu/pub/Larch/lclint">ftp://larch.lcs.mit.edu/pub/Larch/lclint</A>
. Je ne sais pas
ce qu'elle vaut.</P>
<P></P>
<A NAME="index.59"></A> <H2>5.2 <A NAME="ss5.2"></A> Déboguer </H2>
<A NAME="index.62"></A> <A NAME="index.61"></A> <A NAME="index.60"></A> <H3>Comment rendre débogable un programme ? </H3>
<P> Vous devez compiler et effectuer l'édition de liens avec l'option
<CODE>-g</CODE>, et sans l'option <CODE>-fomit-frame-pointer</CODE>.
En fait, vous ne devez compiler que les modules que
vous avez besoin de déboguer.</P>
<P></P>
<P> Si vous possédez un système a.out, les bibliothèques dynamiques sont
compilées avec l'option <CODE>-fomit-frame-pointer</CODE>,
que gcc ne peut pas gérer. Lorsque vous compilez avec l'option
<CODE>-g</CODE>, alors par défaut vous effectuez une édition de liens statique, ce
qui permet de résoudre le problème.</P>
<P></P>
<P> Si l'éditeur de liens échoue avec un message disant qu'il n'arrive
pas à trouver la bibliothèque libg.a, c'est que vous ne possédez pas
la bibliothèque <CODE>/usr/lib/libg.a</CODE>, qui est la bibliothèque C standard
permettant le débogage. Cette bibliothèque est fournie dans
le paquetage des binaires de la libc., ou (dans les nouvelles versions)
vous aurez besoin de récupérer le source et de le compiler vous-même.
Vous n'avez pas réellement besoin de cela en fait, vous pouvez faire
un lien logique vers <CODE>/usr/lib/libc.a</CODE></P>
<P></P>
<A NAME="index.63"></A> <H3>Comment réduire la taille des exécutables ? </H3>
<P> Bon nombre de produits GNU sont fournis pour compiler avec l'option
<CODE>-g</CODE>, ce qui génère des exécutables d'une taille très importante (et
souvent l'édition de liens s'effectue d'une manière statique).
Ce n'est pas une idée lumineuse...</P>
<P></P>
<P> Si le programme possède le script <CODE>configure</CODE> généré par
autoconf, vous pouvez modifier les options de débogage en
effectuant un
<CODE>./configure CFLAGS=</CODE> ou <CODE>./configure CFLAGS=-O2</CODE>. Sinon,
vous pouvez aller modifier le Makefile. Bien sûr, si vous utilisez le format
ELF, l'édition de liens sera effectuée de manière dynamique même avec l'option
<CODE>-g</CODE>. Dans ce cas, vous pouvez effectuer un strip sur l'exécutable.</P>
<P></P>
<A NAME="index.64"></A> <H3>Programmes disponibles </H3>
<P> Beaucoup de gens utilisent <B>gdb</B>, que vous pouvez récupérer
sur le site
<A HREF="ftp://prep.ai.mit.edu/pub/gnu">prep.ai.mit.edu</A>
,
sous une forme binaire sur
<A HREF="ftp://tsx-11.mit.edu/pub/linux/packages/GCC">tsx-11</A>
ou
sur sunsite. <B>xxgdb</B> est une surcouche X de gdb (c.a.d. que vous
avez besoin de gdb pour utiliser xxgdb). Les sources peuvent être récupérés
sur
<A HREF="ftp://ftp.x.org/contrib/xxgdb-1.08.tar.gz">ftp://ftp.x.org/contrib/xxgdb-1.08.tar.gz</A>
</P>
<P>Il existe également le débogueur <B>UPS</B> qui a été porté par Rick Sladkey.
Il fonctionne sous X également, mais à la différence d'xxgdb, ce n'est
qu'une surcouche X pour un débogueur en mode en texte. Il possède
certaines caractéristiques très intéressantes et si vous utilisez beaucoup
ce genre d'outils, vous l'essayerez sûrement. Les patches ainsi que
des versions précompilées pour Linux peuvent être trouvées sur
<A HREF="ftp://sunsite.unc.edu/pub/Linux/devel/debuggers/">ftp://sunsite.unc.edu/pub/Linux/devel/debuggers/</A>
, et les sources
peuvent être récupérés sur
<A HREF="ftp://ftp.x.org/contrib/ups-2.45.2.tar.Z">ftp://ftp.x.org/contrib/ups-2.45.2.tar.Z</A>
.</P>
<P>Un autre outil que vous pouvez trouver utile pour déboguer est
" <B>strace</B> " , qui affiche les appels systèmes que le processus
lance. Il possède d'autres caractéristiques telles que donner les chemins
d'accès où ont été compilés les binaires, donner les temps
passés dans chacun des appels systèmes, et il vous permet également de
connaître les résultats des appels. La dernière version de strace
(actuellement la version 3.0.8) peut être trouvée sur
<A HREF="ftp://ftp.std.com/pub/jrs/">ftp://ftp.std.com/pub/jrs/</A>
.</P>
<P></P>
<H3>Programmes en tâche de fond (démon) </H3>
<P> Les démons lancent typiquement un <CODE>fork()</CODE> dès leur lancement et
terminent donc le père. Cela fait une session de déboguage très courte.</P>
<P></P>
<P> La manière la plus simple de résoudre ce problème est de poser
un point d'arrêt sur <CODE>fork</CODE>, et
lorsque le programme s'arrête, forcer le retour à 0.</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
(gdb) list
1 #include <stdio.h>
2
3 main()
4 {
5 if(fork()==0) printf("child\n");
6 else printf("parent\n");
7 }
(gdb) break fork
Breakpoint 1 at 0x80003b8
(gdb) run
Starting program: /home/dan/src/hello/./fork
Breakpoint 1 at 0x400177c4
Breakpoint 1, 0x400177c4 in fork ()
(gdb) return 0
Make selected stack frame return now? (y or n) y
#0 0x80004a8 in main ()
at fork.c:5
5 if(fork()==0) printf("child\n");
(gdb) next
Single stepping until exit from function fork,
which has no line number information.
child
7 }
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P></P>
<H3>Fichiers core</H3>
<P> Lorsque Linux se lance, il n'est généralement pas configuré
pour produire des fichiers core. Si vous les voulez vous devez utiliser
votre shell pour ça en faisant sous csh (ou tcsh) :
<BLOCKQUOTE><CODE>
<PRE>
% limit core unlimited
</PRE>
</CODE></BLOCKQUOTE>
avec sh, bash, zsh, pdksh, utilisez
<BLOCKQUOTE><CODE>
<PRE>
$ ulimit -c unlimited
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P></P>
<P>Si vous voulez pousser le vice à nommer votre fichier core (par exemple
si vous utilisez un débogueur bogué... ce qui est un comble)
vous pouvez simplement modifier
le noyau. Editez les fichiers <CODE>fs/binfmt_aout.c</CODE> et
<CODE>fs/binfmt_elf.c</CODE> (dans les nouveaux noyaux, vous devrez
chercher ailleurs) :</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
memcpy(corefile,"core.",5);
#if 0
memcpy(corefile+5,current->comm,sizeof(current->comm));
#else
corefile[4] = '\0';
#endif
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>et changez les <CODE>0</CODE> par des <CODE>1</CODE>.</P>
<P></P>
<H2>5.3 <A NAME="ss5.3"></A> Caractéristiques du programme</H2>
<P>Il est possible d'examiner un peu le programme pour
savoir quels sont les appels de fonctions qui sont effectués le
plus souvent ou bien qui prennent du temps. C'est une bonne manière
d'optimiser le code en déterminant là où l'on passe le plus de temps.
Vous devez compiler tous les objets avec l'option <CODE>-p</CODE>,
et pour mettre en forme la sortie écran, vous aurez besoin du
programme <CODE>gprof</CODE> (situé dans les <CODE>binutils</CODE>).
Consultez les pages de manuel <CODE>gprof</CODE> pour plus de détails.</P>
<P></P>
<HR>
<P>
Chapitre <A HREF="GCC-HOWTO-6.html">suivant</A>,
Chapitre <A HREF="GCC-HOWTO-4.html">Précédent</A>
<P>
Table des matières de <A HREF="GCC-HOWTO.html#toc5">ce chapitre</A>,
<A HREF="GCC-HOWTO.html#toc">Table des matières</A> générale</P>
<P>
<A HREF="GCC-HOWTO.html">Début</A> du document,
<A HREF="#0"> Début de ce chapitre</A></P>
</BODY>
</HTML>
