Est-ce que quelqu'un connaitrait un profiler pour linux fonctionnant par interruption et pouvant etre attache a un process en cours d'execution?
Merci
Version imprimable
Est-ce que quelqu'un connaitrait un profiler pour linux fonctionnant par interruption et pouvant etre attache a un process en cours d'execution?
Merci
peux-tu préciser un peu stp ce que tu entends par "fonctionnant par interruption" ?
En fait, je cherche aCitation:
Envoyé par souviron34
- ne pas avoir besoin d'instrumenter le code
- ne pas devoir utiliser qqch comme valgrind qui interprete le code.
La seule technique que je connaisse qui remplisse mes contraintes est de s'attacher (comme un debugger) en laissant tourner l'appli et regulierement l'arreter et faire une capture de la pile d'appel.
A+
--
Jean-Marc
et pourquoi pas ddd ??
ca marche bien
Code:ddd -pid .....
Je confirme souviron34.
gdb peutc très débugguer un programme déjà lancé.
Code:gdb program pid
Je ne parle pas de debugger, mais de profiler -> optenir qqch de similaire a ce que gprof donne mais sans instrumenter (et j'accepte que ce soit moins precis en fonctionnant par interruption).
ben gcc -p (ou -P) te fais la chose, non ???
tu as le fichier de sortie gmon.out et tu n'as rtien instrumente du tout, tu as juste mis un flag de compil.....
Mais peut-etre que je ne comprend pas tout...
Sans instrumenter ni faire quoi que ce soit sur l'executable ou en changeant la maniere dont on le lance. Je sais, je suis difficile.Citation:
Envoyé par souviron34
si ton prog n'est pas compilé avec les flags spéciaux, ça m'étonnerait que tu trouves.. : il y a des raisons simples : la compil et link ,si on enlève les flags de debug, ne contiennent plus les liens avec les sources... Donc plus de noms de fonctions, variables, etc etc......
Donc si jamais tu trouvais ça, tout ce que ça pourrais faire, c'est t'afficher du code assembleur, avec des MOV .R1 .... pour la gestion des variables , JMP .... pour changer de fonction...
Je ne sais pas si tu as déjà essayer de remonter d'un prog d'assembleur à une fonction, mais c'est pas de la tarte.. Tout un prog, surtout si il est gros, bonne chance !!!!
Workshop le fait depuis au moins 10 ans. (Je n'ai pas besoin d'information à la ligne près, une information par chemin d'appel ou mieux par fonction me suffirait -- et l'info est là, gdb la donne quand on fait un bt sur un exécutable optimisé).Citation:
Envoyé par souviron34
Depuis, j'ai trouvé libunwind et je vais voir si j'arrive à me bâtir quelque chose qui me suffise à partir de cela.
souviron34, c'est pas si méchant que ça l'assembleur. Même le code asm garde une certaine sémantique. Les changements de fonctions c'est pas des jmp mais des call/ret.
De plus il reste un certain nombre d'informations dans l'exécutable si celui-ci n'est pas stripé (option -s de gcc ou commande strip), il reste notamment les noms de fonction, c'est bien suffisant pour construire une pile d'appel.
Théoriquement ça m'a l'air faisable, il suffirait d'attacher le programme à la façon d'un débuggeur et suivre son exécution, non pas pour voir ce qu'il fait mais pour le chronométrer. Cela dit, ça risque de ralentir l'exécution du programme si on veut le suivre instruction par instruction (faudrait pas qu'un call nous échappe), mais si les durées absolues ne t'intéressent pas, c'est pas un problème.
Cela étant dit, je ne connais pas de tool effectuant ce genre d'action.
Il semblerait que qprof utilise la libunwind, mais il ne peut pas travailler sur un processus déjà en mémoire, et utilise la technique du LD_PRELOAD pour redéfinir des fonctions, donc ça ne marche pas sur les programmes stripés ni les programmes linkés statiquement.
Cela dit si tu trouves ton bonheur, je suis preneur. :)
je ne sais pas si tu as déjà essayé (moi oui, professionnellement) de re-construire une bibliothèque de traitement d'images de 5000 à 10000 lignes de code à partir uniquement du .o (généré SANS flag de debug)...Citation:
Envoyé par Celelibi
Ben on avait abandonné...... Et on la refaite de A à Z...
Oui je l'ai déjà fait. Sur des .exe windows (sachant que j'ai pas windows chez moi), et sur un .o parce que le prof nous avait donné un .o de la deuxième partie du projet pour qu'on test la première partie.Citation:
Envoyé par souviron34
Mais c'est vrai que ça dépassait pas quelques centaines de ligne.
Mais c'est clair qu'au niveau du temps passé, il vaut mieux recoder le prog en entier et éventuellement regarder le code assembleur original uniquement en cas d'ambiguïté ou sur un point très technique.