Nous avons testeurs pour notre produit GUI intégré et quand un testeur déclare « test a échoué », il est parfois difficile pour nous développeurs de reproduire le problème exact parce que nous n'avons pas la trace exacte de ce qui s'est passé.
Nous avons actuellement un cadre de journalisation mais les développeurs doivent entrer manuellement ces instructions de journalisation dans le code, ce qui est correct. . . sauf quand un bogue difficile à reproduire se produit et que nous n'avons pas d'instruction de journalisation à l'emplacement «correct», puis lorsque nous recréons, réexécutez le test avec les mêmes étapes, nous obtenons un résultat différent.
NUMÉRO
Nous voudrions une solution dans laquelle le compilateur produit du code d'instrumentation supplémentaire qui nous permet de voir la séquence exacte des événements, y compris, au minimum:
- fonction entrée/sortie (déjà fourni par
-finstrument-functions) - instruction de commande de contrôle entrée ie entrée if/else, quel état de cas Ment nous avons sauté à
Le journal ressemblera à ceci:
int main() entered
if-line 5 entered
else-line 10 entered
void EventLoop() entered
. . .
Certains supplémentaires nice-to-haves sont
- Les valeurs des paramètres sur l'entrée de fonction ET sortie (pour les types passage par référence)
- Fonction valeur de retour
QUESTION
Existe-t-il des outils gcc ou même des outils payés qui peuvent faire cette instrumentation automatiquement?
Il semble que vous ayez besoin d'un débogueur – EOF
@EOF nous avons un débogueur Un débogueur n'enregistre pas le comple te trace d'appel. Mais même si c'est le cas, nous voulons que la capacité de trace sans débogueur – Adrian
À moins que vous ayez beaucoup d'optimisations d'appel, une pile doit vous donner la séquence d'appels requise. Peut-être que vous pouvez demander aux testeurs de provoquer une coredump en envoyant un signal approprié? – EOF