Journal : Générateur de graphes d'appels de fonctions
Posté par Pierre Pronchery (page perso, ) le 25 juin 2008
La dépêche récente sur CodeSwarm m'a fait penser que ceci pourrait en intéresser. Je travaille sur un générateur de graphes d'appels de fonctions (en C pour du C). Quelques résultats sont visibles sur mon blog: http://people.defora.org/~khorben/200806.html
Je pourrais même écrire de la documentation si demandé. Les limitations actuelles comprennent:
Tout le nécessaire se trouve dans le CVS de mon projet d'OS (un de plus):
Il faut notamment, dans l'ordre: System/src/libSystem, Apps/Devel/src/cpp, Apps/Devel/src/as, Apps/Devel/src/c99.
Le grapheur est un module du compileur, choisi avec "c99 -M graph". Il génère des fichiers au format "dot" pour conversion avec graphviz.
Je conseille d'installer mes binaires en dehors d'un chemin du $PATH, sinon gcc risque ne va plus trouver ses petits (notamment cpp et as).
Pour conclure, je reconnais qu'il existe déjà des logiciels libres pour le faire. En plus, une bonne partie de mon code n'est pas libre pour l'instant. Mais c'était "facile" à faire avec le design ambitieux de mon compileur C (multi-OS et multi-plateformes par défaut notamment).
Merci d'avoir suivi cette auto-promotion :)
Je pourrais même écrire de la documentation si demandé. Les limitations actuelles comprennent:
- le pré-processeur n'est pas fini (notamment #if, les substitutions, et les commentaires dans les directives)
- en conséquence, seuls les en-têtes (encore incomplets) de ma libc sont supportés (à ma connaissance)
- fonctionne mieux sur NetBSD, puis Linux, puis FreeBSD ou OpenBSD, puis Solaris
Tout le nécessaire se trouve dans le CVS de mon projet d'OS (un de plus):
$ cvs -d:pserver:anonymous@cvs.defora.org:/Data/CVS co DeforaOS
Il faut notamment, dans l'ordre: System/src/libSystem, Apps/Devel/src/cpp, Apps/Devel/src/as, Apps/Devel/src/c99.
Le grapheur est un module du compileur, choisi avec "c99 -M graph". Il génère des fichiers au format "dot" pour conversion avec graphviz.
Je conseille d'installer mes binaires en dehors d'un chemin du $PATH, sinon gcc risque ne va plus trouver ses petits (notamment cpp et as).
Pour conclure, je reconnais qu'il existe déjà des logiciels libres pour le faire. En plus, une bonne partie de mon code n'est pas libre pour l'instant. Mais c'était "facile" à faire avec le design ambitieux de mon compileur C (multi-OS et multi-plateformes par défaut notamment).
Merci d'avoir suivi cette auto-promotion :)
> Lire le journal (12 commentaires, moyenne: 2,7).
Vous avez demandé le commentaire #944000.
Run by 
Cette page a été générée par Templeet en 0.046s (dont 0.0053 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Dans le même genre
Hier, je cherchais comment utiliser l'options -finstrument-functions de gcc et je suis tombé sur ce lien : http://www-128.ibm.com/developerworks/linux/library/l-graphv(...)
C'est assez différent puisque ça fait un graphe d'appels suite à une exécution et non un graphe d'appels statiques. À la vue des images données en exemple, il y a une idée que tu pourrais leur reprendre. C'est celle de l'utilisation de label sur les transitions pour indiquer le nombre d'appels. Ça te permettrait d'alléger le graphes.
Bon, c'est pas tout ça, j'ai un deadlock à éradiquer
[^]Re: Dans le même genre
Un autre outil qui fait des graphes dynamique
valgrind --tool=callgrind (à utiliser avec kcachegrind)
http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGr(...)
En plus il donne le temps CPU pris par chaque fonction.
L'inconvénient c'est que c'est lent !
[^]Re: Dans le même genre
Voir aussi: http://www.suse.de/~krahmer/instrumental/
khorben