C++/Unix - Détecter le début de l'éxecution d'une focntion

Version imprimable

06/05/2010, 12h23
mehdi_me85

C++/Unix - Détecter le début de l'éxecution d'une focntion

Bonjour,

J'essaye de concevoir un outil pour le calcul de la durée de l'exécution de mes fonctions, mais j'ai dû mal à avancer pour le moment.
Mon idée est de développer une fonction que je peux appeler à parti de mon terminal quand je le souhaite (pour cette étape, je n'ai pas problème), que je lui donne en paramètre le nom de la classe et le nom de la fonction, et qui va détecter le début et la fin de l'exécution, de la fonction en paramètre, dés que la fonction est exécutée.
Est ce que vous connaissez une méthode, fonction, outil ou n'importe quelle piste qui peut m'aider à trouver une réponse ?

Je vous remercier d'avance.
07/05/2010, 01h10
LittleWhite

Bonjour,

Le seul endroit ou je vois que vous pouvez avoir de l'aide, c'est dans le code de gdb, ou celui de valgrind.
Peut être au moins juste pour savoir les bibliothèque qu'ils utilisent, car ils ont des bibliothèques spécialement conçu pour ce genre de trucs.
07/05/2010, 07h15
3DArchi

Salut,
Ce genre d'instrumentation est effectivement typique des debuggers.
Sinon, dans un premier temps, tu peux regarder si la programmation par aspect peut t'aider à constituer une instrumentation 'statique' de ton code.
07/05/2010, 09h52
mehdi_me85

Merci pour vos réponses :

Citation:

le code de gdb, ou celui de valgrind.

Je vais chercher le code source de gdb, surtout la fonction "breackpoint" pour avoir plus d'information. Valgrind, je connais pas, mais je vais chercher avant de poser des questions.

Citation:

tu peux regarder si la programmation par aspect peut t'aider à constituer une instrumentation 'statique' de ton code.

Actuellement je ne connais pas la programmation par aspect, et une refonte du code ne parait pas envisageable (Je travaille sur application énorme et complexe).
Mais j'ai une petite question, qu'est ce que tu veux dire par "une instrumentation 'statique' de ton code" ?
Merci d'avance.
07/05/2010, 10h21
LittleWhite

Citation:

Envoyé par mehdi_me85

Je vais chercher le code source de gdb, surtout la fonction "breackpoint" pour avoir plus d'information. Valgrind, je connais pas, mais je vais chercher avant de poser des questions.

Valgrind est un outil perfectionné permettant entre autre de voir les fuites de mémoire ( sa principale utilisation ). Mais il peut aussi être comparé à un débuggeur à part entière.

Citation:

Envoyé par mehdi_me85

Actuellement je ne connais pas la programmation par aspect, et une refonte du code ne parait pas envisageable (Je travaille sur application énorme et complexe).
Mais j'ai une petite question, qu'est ce que tu veux dire par "une instrumentation 'statique' de ton code" ?
Merci d'avance.

J'ai l'impression que cela voulait dire, ajouter des lignes de code à la main pour faire ce qui est voulu ( genre des printf en début de fonction ). Si ce n'est pas ça, je suis aussi très intéressé par la réponse.
Chose à savoir, il peut être une bonne idée de faire un code comme suit ( c'est ce que je fais dans mon dernier projet ):
[code]
#ifdef _INTRUMENTATION
printf("Hello, I am here!\n");
#endif

Ce qui permet de choisir ou non si le code aura cette ligne, à la compilation.
07/05/2010, 10h28
mehdi_me85

Citation:

Chose à savoir, il peut être une bonne idée de faire un code comme suit ( c'est ce que je fais dans mon dernier projet ):
[code]
#ifdef _INTRUMENTATION
printf("Hello, I am here!\n");
#endif

Cette solution, sauf erreur de ma part, consiste à définir la variable _INTRUMENTATION au début de la fonction et surtout avant la compilation. Le souci est que je cherches une solution qui me permettra d'interagir avec l'application en temps réel, sans compiler à chaque fois que je veux faire ou arrêter mon traitement.

Merci de me corriger si je me trompes.
07/05/2010, 10h31
LittleWhite

Citation:

Envoyé par mehdi_me85

Cette solution, sauf erreur de ma part, consiste à définir la variable _INTRUMENTATION au début de la fonction et surtout avant la compilation. Le souci est que je cherches une solution qui me permettra d'interagir avec l'application en temps réel, sans compiler à chaque fois que je veux faire ou arrêter mon traitement.

Merci de me corriger si je me trompes.

Petite précision, certes ma solution n'est pas temps réel, mais peut être désactivé ( ou activée ) à la compilation ( lors de l'appel à gcc ).
Par exemple si je compile avec:

Citation:

gcc main.c -o main

Il n'y aura pas mon code d'instrumentation. Par contre

Citation:

gcc -D_INTRUMENTATION main.c -o main

Il sera présent
07/05/2010, 10h42
mehdi_me85

Citation:

Petite précision, certes ma solution n'est pas temps réel, mais peut être désactivé ( ou activée ) à la compilation ( lors de l'appel à gcc ).

Certes, mais je ne peux pas me permettre une compilation à chaque activation ou désactivation de mon traitement.
Merci pour la précision.
07/05/2010, 12h57
3DArchi

Citation:

Envoyé par LittleWhite

J'ai l'impression que cela voulait dire, ajouter des lignes de code à la main pour faire ce qui est voulu ( genre des printf en début de fonction ).

Sur le principe c'est à peu près ça (sauf pour le printf :mouarf:). La programmation par aspect te permet de ne pas être intrusif à l'écriture de ton code à instrumenter : ton code reste inchangé et tu rajoutes un aspect d'instrumentation 'à côté'. Cependant, après avoir fait tourner toutes les moulinettes et les compilateurs, tu auras bien une instrumentation rajoutée en début et en fin de fonction dans ton binaire. Mais au niveau de tes sources, cette instrumentation n'apparait pas. C'est la force de la programmation orientée aspect et c'est pour ça qu'elle a été réfléchie. (tu peux regarder du côté de AspectC++ ou AOSD pour avoir du blabla là dessus).

Sinon, mehdi_me85 : quel est ton problème exactement et que peux tu faire en terme de modif de code ? Car j'ai l'impression que tu risques de te lancer dans quelque chose de pas du tout trivial (un debugger c'est loin d'être trivial ... surtout pour instrumenter du release). Peut être qu'une autre approche est plus intéressante.
07/05/2010, 14h28
mehdi_me85

Mon objectif est de pouvoir détecter le moment où mon programme entre dans une fonction, précisé dans un paramètre, et le moment où mon programme sort de cette fonction.
La programmation par aspect me semble très intéressante si je trouve un moyen pour la manipuler en temps réel, sans passer par une compilation.
07/05/2010, 15h34
Obsidian

Bonjour,

Citation:

Envoyé par mehdi_me85

J'essaye de concevoir un outil pour le calcul de la durée de l'exécution de mes fonctions [...] je lui donne en paramètre le nom de la classe et le nom de la fonction, et qui va détecter le début et la fin de l'exécution, de la fonction en paramètre, dés que la fonction est exécutée.

Citation:

Envoyé par mehdi_me85

Mon objectif est de pouvoir détecter le moment où mon programme entre dans une fonction, précisé dans un paramètre, et le moment où mon programme sort de cette fonction.

C'est le principe du profiler. Il existe sous Unix les outils prof et gprof (GNU) qui servent à cela. Il faut, pour les utiliser, utiliser respectivement les options -p ou -pg à la compilation pour que le programme exécutable génère un fichier de sortie (gmon.out) qui sera ensuite interprété par l'utilitaire choisi et qui donnera tout un tas de statistiques sur le graphe des appels et le temps passé dans chaque fonction.

Si ton objectif est simplement de monitorer les appels passés au système ou aux différentes bibliothèques, utilise directement strace (truss sous Solaris) ou ltrace. Pas de recompilation nécessaire de ce coté-là.

Citation:

Envoyé par LittleWhite

Le seul endroit ou je vois que vous pouvez avoir de l'aide, c'est dans le code de gdb, ou celui de valgrind. Peut être au moins juste pour savoir les bibliothèque qu'ils utilisent, car ils ont des bibliothèques spécialement conçu pour ce genre de trucs.

Les bibliothèques, et même les applications comme gdb et valgrind ne sont que du code exécuté en userland. Les mécanismes sur lesquels s'appuient ces fonctionnalités sont encore en amont, et c'est eux qu'ils faut chercher. Notamment dans les appels système.
07/05/2010, 15h45
mehdi_me85

Merci Obsidian pour tes précisions.

Citation:

C'est le principe du profiler. Il existe sous Unix les outils prof et gprof (GNU) qui servent à cela. Il faut, pour les utiliser, utiliser respectivement les options -p ou -pg à la compilation pour que le programme exécutable génère un fichier de sortie (gmon.out)

J'utilise aCC pour compiler, est-ce qu'il suffit d'ajouter l'option -p ou -pg lors de la compilation pour générer gmon.out ?

Citation:

qui sera ensuite interprété par l'utilitaire choisi et qui donnera tout un tas de statistiques sur le graphe des appels et le temps passé dans chaque fonction.

Le fichier gmon.out est générer à quel moment ? et comment préciser l'utilitaire qu'on souhaite ?

Citation:

utilise directement strace (truss sous Solaris) ou ltrace.

strace ne me donne aucun résultat quand j'essaye de le tester. Est-ce qu'il faut une configuration particulière ou des arguments ?

Merci d'avance.
07/05/2010, 18h58
Obsidian

Citation:

Envoyé par mehdi_me85

J'utilise aCC pour compiler, est-ce qu'il suffit d'ajouter l'option -p ou -pg lors de la compilation pour générer gmon.out ?

Je n'en sais rien, je n'ai jamais encore utilisé aCC. Essaie, ou regarde la doc, et fais-nous part de tes découvertes.

Citation:

Le fichier gmon.out est généré à quel moment ? et comment préciser l'utilitaire qu'on souhaite ?

gmon.out est généré à l'exécution de ton programme, s'il a été compilé au préalable avec les bonnes options. C'est le résultat proprement dit. Ce fichier est ensuite analysé par prof ou gprof.

Citation:

strace ne me donne aucun résultat quand j'essaye de le tester. Est-ce qu'il faut une configuration particulière ou des arguments ?

Non, ça devrait marcher tout seul. Il est peu probable que ton programme ne fasse aucun appel au système, même sous-jacent.

Tu travailles avec quel système d'exploitation ?
10/05/2010, 09h58
mehdi_me85

Merci Obsidian pour tes précisions.

Citation:

Tu travailles avec quel système d'exploitation ?

Je travaille avec UNIX.

Citation:

Essaie, ou regarde la doc, et fais-nous part de tes découvertes

Je vais essayer d'avancer dans ce sens, et je publierai la méthode si ça marche.
10/05/2010, 12h17
mehdi_me85

Citation:

Citation:

strace ne me donne aucun résultat quand j'essaye de le tester. Est-ce qu'il faut une configuration particulière ou des arguments ?

Non, ça devrait marcher tout seul. Il est peu probable que ton programme ne fasse aucun appel au système, même sous-jacent.

J'utilise HP-UNIX, et c'est pourquoi struss ne donne pas de résultats. L'équivalent de struss sous HP-UNIX est tusc. Il n'est pas disponible sous HP-UNIX par défaut, mais vous pouvez l'installer à partir de ce lien.
Je suis entrain de chercher la doc de cette commande, si vous avez des liens vers un tuto ou une doc intéressante, Merci de m'en faire part.

Merci.
18/05/2010, 17h01
mehdi_me85

Bonjour,

L'outil 'tusc' ne répond pas à mes exigences, du coup je m'intéresse au deboguer valgrind. Je cherche un tutoriel détaillé de l'utilisation de ce logiciel mais je n'ai rien trouvé pour le moment. Est-ce que vous avez une idée ou je peux trouver un manuel d'installation et un manuel d'utilisation.

Merci par avance.
18/05/2010, 17h16
ram-0000

ici : http://matthieu-brucher.developpez.c...visual-studio/ ?

Merci pour ta réponse,

J'ai aussi trouvé cette doc officielle.
Cependant, je travaille avec aCC et visiblement valgrind ne marche qu'avec gCC. quand j'essaie de le configurer j'ai ce message d'erreur :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 checking for a BSD-compatible install... ./install-sh -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... no checking for nawk... no checking for awk... awk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking whether ln -s works... yes checking for gcc... aCC checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details.
Est ce que vous savez un moyen pour faire marcher valgrind avec aCC ?
Merci d'avance.