Fonctions statiques et non statiques - Débogage dans le contexte des systèmes embarqués

Question

La question suivante m'a laissé perplexe : Comment conserver l'avantage du label "statique" tout en étant capable de déboguer le code de production sur place ?

Il n'arrive pas qu'un comportement involontaire se produise sur le site du client, et seulement là . Dans de nombreux cas, la possibilité d'effectuer un débogage peut permettre d'économiser beaucoup d'efforts et d'obtenir une réponse très rapide. Un tel débogage implique généralement de vérifier le comportement de la fonction, ce qui nous amène à la définition "statique".

Les fonctions statiques ne peuvent pas être déboguées à partir d'un shell de débogage, par exemple en plaçant des points d'arrêt ou en les exécutant. D'autre part, définir toutes les fonctions comme publiques entraîne des problèmes de structure et d'optimisation du code.

Je suis conscient de l'existence d'options telles que la compilation d'au moins deux versions différentes, l'une avec statique et l'autre sans, mais cela convient bien aux tests d'automatisation, et non à la version finale de production qui sera finalement publiée.

J'apprécierais que vous me donniez votre avis, notamment sur la manière dont vous avez résolu (le cas échéant) ce dilemme. Ou en reformulant la question comme suit : " Qu'est-ce qui est le plus important ? "

Une bonne discussion sur les "statiques" en C aquí .

Answer 1

Je pense que la question fondamentale n'est pas " Est-ce que vous livrez avec "statique" ou non ? ", c'est " Testez-vous exactement ce que vous expédiez ?" Pour le code embarqué, si vous effectuez la majorité de vos tests sur une version de débogage, puis expédiez une version de validation compilée avec différentes options, vous expédiez essentiellement du code non testé à votre client. Lorsque vous travaillez aussi près du matériel, de petits changements dans le timing ou les modèles d'accès à la mémoire (que l'optimiseur peut facilement introduire) peuvent provoquer de grands changements dans le comportement du système.

Ma stratégie actuelle est d'envoyer la version de débogage, configurée pour une optimisation aussi poussée que possible lors du débogage. Pas de fonctions statiques, autant d'états que possible visibles par le débogueur.

Oui, j'abandonne certaines efficacités possibles générées par le compilateur, mais tant que je m'assure que la version Debug est suffisamment rapide pour répondre à ses exigences, ce n'est pas un problème. Et la récompense est que le code que je livre est exactement le même que celui que j'ai testé pendant tout le cycle de publication - aucune surprise générée par l'optimiseur.

Answer 2

Pouvez-vous placer un point d'arrêt dans la fonction accessible au public qui appelle la fonction statique ? Vous pourriez alors vérifier les arguments entrant et les valeurs de retour au moins. Si le problème ne se produit que sur le site d'un client, et que vos tests unitaires / tests d'intégration ne montrent pas de problèmes pour les entrées que vous vous attendez à ce que ces fonctions reçoivent, le problème est probablement que ces fonctions reçoivent des entrées (ou une séquence d'entrées, si la fonction est stateful d'une certaine manière) que vous n'avez pas anticipées, ce qui signifie que le problème réel peut se situer en dehors des fonctions statiques que vous regardez.

Si vous pensez déjà savoir quelle fonction statique contient le problème, et que vous connaissez le type d'entrées que vous soupçonnez être à l'origine du problème, vous pouvez mettre une simple fonction de test unitaire dans le build de la version, juste pour vérifier le bogue que vous soupçonnez. Bien sûr, cela se complique si cette fonction contrôle directement, par exemple, une grue de six tonnes, auquel cas vous devrez écrire deux versions de la fonction, l'une avec une maquette pour contrôler la grue, et exécuter vos tests sur celle-ci.

Le moins probable mais pas impossible, n'excluez jamais une incohérence du compilateur entre les versions release et debug. Nous aimons tous penser que les compilateurs sont infaillibles, moi y compris, mais des choses arrivent. Et je vois dans votre réponse à torek que donner au client une version de débogage résout parfois les problèmes...