J'ai la question suivante et une perspective des systèmes veulent savoir comment atteindre cela facilement et efficacement.
Compte tenu d'une tâche 'ABC' qui a été construit avec des informations de débogage et une variable globale "TRACE" qui est normalement définie sur 0, j'aimerais imprimer pour fichier "log" l'adresse de chaque fonction appelée entre le temps que la trace est réglée sur 1 et retour à 0.
J'avais envisagé de le faire via une tâche de chargement de chargement frontal / de démarrage que je développerais, qui examine les instructions d'un modèle commun de pointeur de saut / de cadre Poussez, écrivez l'adresse, puis en mappant les adresses des noms de fonctions. des informations de débogage symboliques dans ABC. Il pourrait y avoir de meilleures façons de niveau du système de le faire sans une chargeuse frontale, et je ne suis pas sûr de ce qui est le plus réalisable.
Toute technique implémentée là-bas?
3 Réponses :
Assurez-vous que vous avez examiné les identifiants prédéfinis __func__ ou __fonction__. Ils fournissent un littéral à chaîne du nom de la fonction / de la méthode que vous exécutez actuellement.
Une possibilité est de prétraiter la source avant de la compiler. Ce prétraitement ajouterait du code au début de chaque fonction qui vérifierait la trace globale et, le cas échéant, écrivez sur le journal. Comme le dit MyStagogue, le compilateur a des macros de préprocesseur qui s'étendent au nom de la fonction.
Vous pouvez également regarder certains outils de profilage. Certains d'entre eux ont une fonctionnalité proche de ce que vous demandez. Par exemple, certains échantillonneront périodiquement l'intégralité de CallStack, qui peut vous en dire beaucoup sur le flux de code sans enregistrer tous les appels.
Les sources de prétraitement pourraient être l'une des façons les moins chères de le faire.
Nous devons vous connecter à chaque appel. Je pourrais utiliser Dtrace pour obtenir des piles périodiques haute fréquence, mais cela ne va pas faire l'affaire. Les sources de prétraitement pourraient, mais nos fichiers binaires atteignent déjà la limite de GIG 32 bits 4. Merci
À la recherche d'un prologue commun / épilogue ne fonctionnera pas en présence d'une omission de pointeur et d'une optimisation des appels de queue. En outre, les optimiseurs modernes aiment diviser les fonctions en plusieurs morceaux et fusionnez des morceaux communs de différentes fonctions.
Il n'y a pas de solution standard.
pour Microsoft Compiler, consultez _penter et _ PEXIT Hooks. Pour GCC, regardez -Finstrument-Fonctions < / a> option et amis.
En outre, sur X86 Windows, vous pouvez utiliser un moniteur tel que Winapioverride32 . Il est principalement destiné à la surveillance des appels d'API DLL et système, mais vous pouvez générer un fichier de description dans le fichier de carte de votre application et surveiller les fonctions internes.
( édité: ajout de lien vers l'option GCC. )
Je suis d'accord - merci pour les commentaires. Le débogueur 'DBX' semble être capable de le faire, cependant, donc je ne pense pas qu'il y a une optimisation des appels queue - ou comment DBX pourrait-il comprendre? Si le débogueur peut le faire, nous devrions être capables de. Le problème est que ce n'est évidemment pas pratique d'avoir ceci chargé dans DBX dans un environnement de production. L'idée était donc de faire le travail minimum nécessaire dans une tâche de chargement frontal similaire qui peut dire lorsque les fichiers binaires appellent des fonctions. Même au pire des cas, je pourrais enregistrer tous les sauts, ce qui montrerait également un flux intra-fonction (bien bruyant).
J'espère que les fonctions -Finstrument :) vont enquêter plus loin .. beaucoup merci
Les profilers peuvent déjà faire cela pour vous - affichant même le nom de la fonction au lieu de l'adresse. Pourquoi ils ne fonctionnent pas pour vous?
Pourquoi êtes-vous intéressé par l'adresse de la fonction au lieu de son nom? En outre, il est utile de savoir quel OS et votre compilateur vous utilisez.
J'utilise GCC / CC / XLC sur HP / Sun / IBM. Je suis finalement intéressé par le nom des fonctions; L'adresse était prévue comme un intermédiaire et peut être inutile. Merci.
DUMYS00001: Cela doit être activé en direct pour d'énormes binaires de production (2-4gigs) très redondants / disponibles. Ils ne courent pas à travers un profileur. Nous devons piéger le flux de clients tout en étant incapable d'être le client. Le profileur n'est pas une option.