FR3110982A1 - Procédé d'observation d'exécution d'une composante logicielle, et produit programme d'ordinateur et système d'observation associés - Google Patents
Procédé d'observation d'exécution d'une composante logicielle, et produit programme d'ordinateur et système d'observation associés Download PDFInfo
- Publication number
- FR3110982A1 FR3110982A1 FR2005568A FR2005568A FR3110982A1 FR 3110982 A1 FR3110982 A1 FR 3110982A1 FR 2005568 A FR2005568 A FR 2005568A FR 2005568 A FR2005568 A FR 2005568A FR 3110982 A1 FR3110982 A1 FR 3110982A1
- Authority
- FR
- France
- Prior art keywords
- instrumentation
- function
- instrumented
- instruction
- software component
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3624—Software debugging by performing operations on the source code, e.g. via a compiler
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
Procédé d’observation d’exécution d’une composante logicielle, et produit programme d’ordinateur et système d’observation associés La présente invention concerne un procédé d’observation d’exécution d’une composante logicielle comprenant une phase d’instrumentation (PI) mise en œuvre préalablement à l’exécution de la composante logicielle et une phase d’enregistrement (PE) mise en œuvre lors de l’exécution de la composante. La phase d’instrumentation comprend de détermination (130) de fonctions à instrumenter ; de détermination (132) d’un type d’instrumentation choisi parmi un jeu prédéterminé de types d’instrumentation ; et d’instrumentation (140) de chaque fonction à instrumenter pour obtenir une fonction instrumentée. La phase d’enregistrement (PE) comprend l’étape d’enregistrement (160) dans un tampon de traces d’au moins certaines traces générées par au moins une instruction d’instrumentation lors de l’exécution de la fonction instrumentée associée à cette instruction d’instrumentation. Figure pour l'abrégé : figure 2
Description
La présente invention concerne un procédé d’observation d’exécution d’une composante logicielle.
La présente invention concerne également un produit programme d’ordinateur et un système d’observation associés à ce procédé d’observation.
L’invention permet en particulier d’observer le fonctionnement d’une composante logicielle en générant des traces relatives au fonctionnement de différentes fonctions formant cette composante logicielle. Ces traces, générées à l’entrée ou à l’entrée et à la sortie de la fonction correspondante, permettent par exemple de contrôler les entrées ou les sorties de cette fonction afin de déterminer un éventuel disfonctionnement ou une erreur de programmation dans cette fonction et/ou dans des fonctions liées à cette fonction.
Autrement dit, ces traces permettent la mise au point de la composante logicielle par exemple au cours de son développement ou au cours de la phase de test de celle-ci.
Dans l’état de la technique, de nombreux moyens d’investigation des composantes logicielles permettant leur mise au point sont déjà connus.
Parmi ces moyens, on connait notamment des sondes permettant la mise au point d’un logiciel par pose de points d’arrêt (« breakpoints ») et observation de l’état des composantes matérielles utilisables par ce logiciel.
On connait également des outils appelés débogueurs (de l’anglais « debuggers ») permettant d’observer l’état du logiciel. Le fonctionnement de ces débogueurs est mis en œuvre par pose de points d’arrêt dans le logiciel correspondant.
Toutefois, dans les deux cas, les points d’arrêt provoquent l’arrêt du logiciel en cours d’exécution ou de tout le système hébergeant un tel logiciel ce qui n’est pas toujours souhaitable. De plus, dans le cas des sondes, l’accès à l’état des ressources matérielles peut présenter des difficultés.
On connait également des moyens d’investigation permettant l’observation du déroulement de l’exécution d’une composante logicielle par ajout des instructions prédéterminées sur des évènements prédéfinis de cette composante. Ces instructions sont donc ajoutées dans les codes source de la composante logicielle correspondante. Leur fonctionnement peut être activé ou désactivé de manière conditionnelle.
Toutefois, dans un tel cas, l’observation de tout nouvel évènement nécessite une modification et une recompilation de la composante logicielle correspondante car l’intégration d’une nouvelle instruction est nécessaire dans ses codes source. De plus, une fois intégrée, une instruction peut avoir un impact sur les performances de la composante logicielle correspondante même lorsqu’elle n’est pas activée. En outre, l’impact sur l’exécution en temps réel de la composante logicielle peut avoir une influence sur la reproductibilité de l’évènement observé.
Enfin, dans le système d’exploitation Linux, on connait des outils permettant l’observation des objets du noyau du système par ajout des appels du service appelé « mcount » en entrée des fonctions des objets générés.
Toutefois, cette solution n’est pas suffisamment flexible et en particulier, ne peut pas être appliquée à une application quelconque du système. De plus, lorsqu’elle est appliquée aux objets du noyau, cette application se fait de manière homogène pour l’ensemble des objets observés et ne peut pas être affinée en fonction de chaque objet considéré.
La présente invention a pour but de proposer un système et un procédé d’observation flexibles et permettant de mettre au point une composante logicielle quelconque sans dégrader considérablement ses performances et sans avoir à modifier celle-ci.
À cet effet, l’invention a pour objet un procédé d’observation d’exécution d’une composante logicielle comprenant une pluralité de fonctions, au moins certaines fonctions, dites fonctions observables, comprenant chacune un ensemble d’instructions neutres.
Le procédé comprend une phase d’instrumentation mise en œuvre préalablement à l’exécution de la composante logicielle et une phase d’enregistrement mise en œuvre lors de l’exécution de la composante logicielle.
La phase d’instrumentation comprend les étapes suivantes :
- parmi les fonctions observables, détermination de fonctions à instrumenter ;
- pour chaque fonction à instrumenter, détermination d’un type d’instrumentation choisi parmi un jeu prédéterminé de types d’instrumentation ;
- instrumentation de chaque fonction à instrumenter pour obtenir une fonction instrumentée, par association à cette fonction à instrumenter d’une instruction d’instrumentation correspondant au type d’instrumentation déterminé pour cette fonction.
La phase d’enregistrement comprend l’étape suivante :
- enregistrement dans un tampon de traces d’au moins certaines traces générées par au moins une instruction d’instrumentation lors de l’exécution de la fonction instrumentée associée à cette instruction d’instrumentation.
Suivant d’autres aspects avantageux de l’invention, le procédé comprend une ou plusieurs des caractéristiques suivantes, prise(s) isolément ou suivant toutes les combinaisons techniquement possibles :
La phase d’enregistrement comprend en outre l’étape suivante :
- filtrage des traces générées par l’ensemble des instructions d’instrumentation des fonctions instrumentées par un filtre d’activation ;
les traces enregistrées lors de l’étape d’enregistrement correspondant aux traces retenues par le filtre d’activation ;
- chaque instruction d’instrumentation est configurée pour générer des traces à l’entrée de la fonction instrumentée correspondante, ou à l’entrée et à la sortie de la fonction instrumentée correspondante ;
- la phase d’instrumentation comprend en outre une étape de paramétrage d’au moins certaines instructions d’instrumentation, dites instructions d’instrumentation paramétrables, pour les fonctions à instrumenter correspondantes, ladite étape de paramétrage comprenant la détermination de paramètres pour chaque instruction d’instrumentation paramétrable ;
- lors de l’étape d’instrumentation, l’instruction d’instrumentation associée à au moins une fonction instrumentée est injectée dans cette fonction à la place de l’ensemble d’instructions neutres correspondant ;
- lorsque l’instruction d’instrumentation injectée dans la fonction instrumentée correspondante est une instruction d’instrumentation paramétrable, l’étape d’instrumentation comprend en outre l’injection dans cette fonction instrumentée des paramètres correspondant à cette instruction ;
- lors de l’étape d’instrumentation, l’instruction d’instrumentation associée à au moins une fonction instrumentée est injectée dans une zone mémoire distincte de cette fonction instrumentée, l’ensemble d’instructions neutres de cette fonction instrumentée étant remplacé par un branchement vers ladite zone mémoire ;
- lorsque l’instruction d’instrumentation injectée dans ladite zone mémoire est une instruction d’instrumentation paramétrable, l’étape de l’instrumentation comprend en outre l’injection dans cette zone mémoire des paramètres correspondant à cette instruction ;
- chaque ensemble d’instructions neutres est injecté dans la fonction observable correspondante lors de la compilation de la composante logicielle ;
- la composante logicielle est un système d’exploitation ou une application hébergée par un système d’exploitation ou une bibliothèque partagée entre plusieurs applications d’un système d’exploitation hébergeant ces applications ;
- lorsque la composante logicielle est une bibliothèque partagée entre plusieurs applications du système d’exploitation hébergeant ces applications, chaque fonction instrumentée est copiée dans un espace privé d’une application à observer lors de l’étape d’instrumentation.
L’invention a également pour objet un produit programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé tel que défini ci-dessus.
L’invention a également pour objet un système d’observation d’exécution d’une composante logicielle, comprenant des moyens techniques configurés pour mettre en œuvre le procédé tel que défini ci-dessous.
Ces caractéristiques et avantages de l’invention apparaitront à la lecture de la description qui va suivre, donnée uniquement à titre d’exemple non limitatif, et faite en référence aux dessins annexés, sur lesquels :
Un système d’observation 10 est illustré sur la . Ce système d’observation 10 est utilisable pour observer le fonctionnement d’une composante logicielle 13 par exemple d’un système embarqué, notamment d’un système embarqué avionique.
Dans tout ce qui suit, par « composante logicielle », on entend un système d’exploitation, appelé également système OS (de l’anglais « Operating System »), ou toute application hébergée par un tel système d’exploitation, ou encore une bibliothèque partagée entre plusieurs applications d’un système d’exploitation hébergeant ces applications. En particulier, une telle application ou une telle bibliothèque peut faire partie du système d’exploitation ou être fournie par une partie tierce.
De manière connue en soi, la composante logicielle 13 comprend une pluralité de fonctions reliées entre elles. En particulier, ces fonctions sont aptes à faire des appels les unes aux autres lors de l’exécution de la composante logicielle. Chaque fonction appelée est apte à s’exécuter à partir de données d’entrée fournies par une ou plusieurs autres fonctions et lors de son exécution, à générer des données de sortie. Ces données de sortie sont généralement renvoyées vers la fonction ayant appelé cette dernière fonction.
Dans l’exemple décrit, la composante logicielle 13 est stockée dans une mémoire centrale 11 d’un calculateur permettant d’exécuter cette composante. Dans d’autres modes de réalisation, la composante logicielle 13 est stockée dans une mémoire distante du calculateur exécutant cette composante ou est stockée de manière distribuée entre plusieurs mémoires locales et/ou distantes.
En référence à la , le système d’observation 10 comprend un module d’instrumentation 15, un module d’enregistrement 17 et optionnellement, un module de compilation 19.
Ces modules 15, 17 et 19 se présentent sous la forme de logiciels ou alors, au moins partiellement, sous la forme de circuits logiques programmables, par exemple de type FPGA (de l’anglais « Field-Programmable Gate Array »).
Le module d’instrumentation 15 permet d’instrumenter la composante logicielle 13 en mettant en œuvre une phase d’instrumentation PI du procédé d’observation selon l’invention, expliquée en détail par la suite.
Dans tout ce qui suit, par « instrumentation », on entend le fait de rendre au moins une fonction de la composante logicielle apte à produire des traces à des fins d’observabilité de celle-ci. Ainsi, par « instrumenter », on entend l’action permettant de parvenir à une instrumentation d’une fonction.
Pour mettre en œuvre la phase d’instrumentation PI, le module d’instrumentation 15 est connecté à un outil de configuration 21 et à la mémoire centrale 11 qui stocke, outre la composante logicielle 13, une base d’instrumentation 22.
La base d’instrumentation 22 est apte à stocker un jeu prédéterminé de types d’instrumentation.
Chaque type d’instrumentation définit une instruction d’instrumentation utilisable pour générer des traces d’une fonction, comme cela sera expliqué par la suite.
En particulier, par « trace », on entend toute donnée de sortie d’une fonction ou toute autre donnée globale à la composante logicielle 13, permettant de mettre au point cette fonction ou plus globalement, la composante logicielle 13.
Par exemple, une telle trace peut comprendre l’ensemble des données d’entrée reçues par la fonction ou l’ensemble de données de sortie générées par cette fonction ou encore des données globales à la composante logicielle 13. Selon un autre exemple, une trace comprend des données intermédiaires utilisables par cette fonction. Selon encore un autre exemple, une trace est déterminée en fonction d’au moins certaines des données d’entrée et/ou des données de sortie de la fonction correspondante.
Ainsi, chaque instruction d’instrumentation est adaptée pour générer une trace de type donné et présente notamment une pluralité de commandes adaptées à cet effet.
Au moins certaines des instructions d’instrumentation sont paramétrables. Ces instructions d’instrumentation sont dites alors instructions d’instrumentation paramétrables.
Chaque instruction d’instrumentation paramétrable est paramétrable à partir d’un jeu de paramètres, prédéterminé pour cette instruction d’instrumentation ou pour l’ensemble des instructions d’instrumentation paramétrables.
L’outil de configuration 21 permet de déterminer pour au moins certaines fonctions de la composante logicielle 13 le type d’instrumentation devant être mis en œuvre pour une fonction donnée et lorsque ce type correspond à une instruction d’instrumentation paramétrable, un jeu de paramètres utilisable pour cette instruction.
L’outil de configuration 21 se présente par exemple sous la forme d’un logiciel apte à interagir avec un utilisateur via une interface homme-machine adaptée.
Ainsi, cet outil de configuration 21 permet à un utilisateur de choisir des fonctions de la composante logicielle 13 devant être observées, le type d’instrumentation correspondant et éventuellement, un jeu de paramètres utilisable par l’instruction d’instrumentation correspondante.
Le module d’enregistrement 17 permet d’enregistrer au moins certaines des traces lors de l’exécution des fonctions correspondantes en mettant en œuvre une phase d’enregistrement PE du procédé d’observation expliqué en détail par la suite.
Pour ce faire, le module d’enregistrement 17 est connecté à la mémoire centrale 11 dans laquelle il est apte à générer un tampon de traces 25 comportant des traces enregistrées.
Dans un mode de réalisation avantageux de l’invention, le module d’enregistrement 17 permet d’enregistrer des traces conformément à un filtre d’activation. Ce filtre d’activation est par exemple mis en œuvre par l’outil de configuration 21 permettant de déterminer une pluralité de critères selon lesquels les traces sont enregistrées.
Ces critères sont par exemple déterminés par l’utilisateur de manière dynamique, c’est-à-dire lors de l’exécution de la composante logicielle 13, et sont par exemple relatifs à l’ensemble des traces générées par une même fonction. Ainsi, dans un tel cas, l’utilisateur a la possibilité d’activer ou de désactiver l’enregistrement de l’ensemble des traces générées par une fonction donnée.
Selon un autre exemple, au moins certains de ces critères sont relatifs à la nature des traces et permettent donc d’activer ou de désactiver l’enregistrement d’une trace donnée en fonction de cette trace même (par exemple en fonction de sa taille, date de génération, contenu, etc.).
Le module de compilation 19 permet de compiler la composante logicielle 13 lorsqu’elle se présente sous une forme non-compilée, en mettant en œuvre une phase de compilation PC du procédé d’observation, expliquée en détail par la suite.
Pour ce faire, le module de compilation 19 est raccordé à un compilateur 27 correspondant par exemple à un compilateur connu du langage de programmation utilisé lors de la programmation de la composante logicielle 13. En variante, le compilateur 27 présente un compilateur connu modifié.
Le module de compilation 19 permet également d’injecter dans au moins certaines des fonctions de la composante logicielle 13 des instructions neutres afin de rendre ces fonctions observables, comme cela sera également expliqué par la suite.
Le procédé d’observation de la composante logicielle 13 sera désormais expliqué en référence à la présentant un organigramme des étapes de ce procédé.
Comme indiqué précédemment, ce procédé d’observation comprend une phase d’instrumentation PI, une phase d’enregistrement PE et optionnellement, une phase de compilation PC.
La phase de compilation PC est mise en œuvre lorsque la composante logicielle 13 se présente sous la forme non-compilée, c’est-à-dire sous la forme d’un ou de plusieurs codes source. Cette phase de compilation PC comprend les étapes 110 et 120 expliquées en détail ci-dessous.
En particulier, lors de l’étape 110, l’utilisateur choisit l’ensemble des fonctions de la composante logicielle 13 pour lesquelles une observation est nécessaire. Ces fonctions sont alors appelées fonctions observables.
Cela peut être fait en utilisant par exemple l’outil de configuration 21 ou tout autre outil adapté à cet effet.
Puis, lors de la même étape 110, pour chaque fonction choisie par l’utilisateur, c’est-à-dire pour chaque fonction observable, le module de compilation 15 injecte un ensemble d’instructions neutres en entrée de cette fonction.
Un tel ensemble est composé d’une pluralité d’instructions neutres connues sous le terme anglais « NOP » (de l’expression « No Operation ») et présentant chacune par exemple un caractère ou une suite de caractères reconnaissable par le compilateur 27.
Puis, lors de l’étape suivante 120, le module de compilation 19 génère un code binaire exécutable à partir du ou des codes sources de la composante logicielle 13 en utilisant le compilateur 27.
Cette étape 120 est illustrée schématiquement sur la .
Ainsi, dans l’exemple de cette figure, un ensemble d’instructions neutres « nop » est injecté par le compilateur 27 dans chacune des fonctions F1, F2 et F3 de la composante logicielle 13.
Le nombre d’instructions neutres dans un tel ensemble est par exemple choisi en fonction de la taille des instructions d’instrumentation et éventuellement des paramètres de ces instructions qui sont susceptibles d’y être insérés comme cela sera expliqué par la suite.
À la fin de la phase de compilation PC, un code binaire exécutable correspondant à la composante logicielle 13 est alors obtenu. Ce code binaire exécutable comprend des fonctions observables dans lesquelles sont injectées des ensembles d'instructions neutres. Par la suite, le terme « composante logicielle 13 » sera utilisé pour désigner ce code binaire exécutable.
Lorsque la phase de compilation PC n’est pas exécutée par le système d’observation 10, il est considéré que la composante logicielle 13 se présente déjà sous une forme exécutable et qu’au moins certaines de ses fonctions ont été rendues observables par tout autre système externe, en injectant des ensembles d'instructions neutres dans ces fonctions. Par exemple, la composante logicielle 13 peut être fournie par une partie tierce avec au moins certaines de ses fonctions rendues observables.
La phase d’instrumentation PI est lancée par l’utilisateur lorsqu’il souhaite observer le fonctionnement d’au moins certaines fonctions observables de la composante logicielle 13.
Pour cela, lors d’une étape initiale 130 de cette phase d’instrumentation PI, le module d’instrumentation 15 détermine des fonctions à instrumenter parmi l’ensemble des fonctions observables de la composante logicielle 13.
Ces fonctions à instrumenter sont par exemple déterminées à partir des instructions données par l’utilisateur à l’outil de configuration 21.
Lors de l’étape 132 suivante, pour chaque fonction à instrumenter, le module d’instrumentation 15 détermine un type d’instrumentation choisi parmi le jeu prédéterminé de types d’instrumentation de la base d’instrumentation 22.
Comme dans le cas précédent, cela est par exemple fait à partir des instructions données par l’utilisateur à l’outil de configuration 21.
Ensuite, lors de l’étape 134 suivante, le module d’instrumentation 15 détermine pour chaque type d’instrumentation correspondant à une instruction d’instrumentation paramétrable, des paramètres correspondants.
Ces paramètres peuvent également être indiqués par l’utilisateur via l’outil de configuration 21.
Lors de l’étape 140 suivante, le module d’instrumentation 15 instrumente chaque fonction à instrumenter par association à cette fonction à instrumenter d’une instruction d’instrumentation correspondant au type d’instrumentation déterminé pour cette fonction et éventuellement, des paramètres correspondant à cette fonction.
Avantageusement selon l’invention, cette association de la fonction à instrumenter et de l’instruction d’instrumentation et éventuellement des paramètres correspondants, peut être de deux types.
Selon un premier type d’association, l’instruction d’instrumentation et éventuellement les paramètres correspondants sont injectés directement dans la fonction à instrumenter correspondante à la place de l’ensemble d'instructions neutres de cette fonction.
Un exemple d’un tel type d’association est illustré sur la .
En effet, dans l’exemple de cette , l’instruction d’instrumentation « instr1 » avec les paramètres « params1 » sont associés à la fonction F1 par injection de cette instruction d’instrumentation « instr1 » et des paramètres « params1 » directement dans la fonction F1 à la place de l’ensemble d'instructions neutres « nop » correspondants.
De manière analogue, l’instruction d’instrumentation « instr4 » avec les paramètres « params2 » sont associés à la fonction F1 par injection de cette instruction d’instrumentation « instr4 » et des paramètres « params2 » directement dans la fonction F3 à la place de l’ensemble d'instructions neutres « nop » correspondant.
Quant à la fonction F2, celle-ci n’est pas instrumentée et garde donc son ensemble d'instructions neutres « nop » inchangé.
Selon un deuxième type d’association, l’instruction d’instrumentation et éventuellement les paramètres correspondants sont injectés dans une zone mémoire distincte de la fonction instrumentée. Cette zone mémoire est par exemple allouée à cet effet dans une zone mémoire disponible de la composante logicielle 13.
De plus, dans un tel cas, l’ensemble d'instructions neutres de la fonction instrumentée est remplacé par un branchement vers ladite zone mémoire.
La illustre un exemple de ce deuxième type d’association.
En effet, dans l’exemple de la , une zone mémoire T est allouée dans la zone mémoire disponible de la composante logicielle 13. Dans ce cas, l’instruction d’instrumentation « instr1 » avec les paramètres « params1 » correspondants sont injectés dans la zone mémoire T et un branchement B est créé à partir de l’ensemble d'instructions neutres « nop » de la fonction F1 vers cette zone mémoire T.
Dans un exemple de réalisation, au moins certaines fonctions à instrumenter sont instrumentées en utilisant le premier type d’association et certaines autres fonctions à instrumenter sont instrumentées en utilisant le deuxième de type d’association. Selon un autre exemple, l’ensemble des fonctions à instrumenter sont instrumentées en utilisant uniquement l’un des types d’association. Selon encore un exemple de réalisation, le type d’association est choisi pour chaque fonction à instrumenter par l’utilisateur via par exemple les paramètres correspondants.
Par ailleurs, indépendamment du type d’association choisi, chaque fonction à instrumenter peut être instrumentée en entrée, ou en entrée et en sortie de celle-ci.
Dans ce deuxième cas, l’instruction d’instrumentation correspondante modifie en entrée la fonction instrumentée correspondante en insérant un appel à traitement d’au moins une partie de cette instruction à la fin de la fonction instrumentée, puis après cet appel, un retour vers la fonction ayant appelé la fonction instrumentée.
La illustre un exemple d’une telle implémentation dans le cas où l’instruction d’instrumentation « instr1 » avec les paramètres « params1 » correspondants ont été associés à la fonction instrumentée F1 en utilisant le premier type d’association.
En effet, dans l’exemple de cette , lorsque la fonction F0 forme un appel vers la fonction F1, l’instruction d’instrumentation « instr1 » s’exécute en entrée de cette fonction F1 et insère un appel à traitement de l’instruction d’instrumentation « instr1’ » à la fin de cette fonction F1 et puis, après l’exécution de l’instruction d’instrumentation « instr1’ », un retour vers la fonction appelante F0.
De manière analogue, dans l’exemple de la illustrant le deuxième type d’association, lorsque la fonction F0 forme un appel vers la fonction F1, l’instruction d’instrumentation « instr1 » s’exécute à partir de la zone mémoire T en entrée de cette fonction F1. Lors de cette exécution, la fonction d’instrumentation « instr1 » insère un appel à traitement de l’instruction d’instrumentation « instr1’ » à la fin de cette fonction F1 et puis, après l’exécution de l’instruction d’instrumentation « instr1’ », un retour vers la fonction appelante F0.
Dans un mode réalisation particulier de l’invention, lorsque la composante logicielle 13 est une bibliothèque partagée entre plusieurs applications du système d’exploitation hébergeant ces applications, chaque fonction instrumentée est copiée dans un espace privé d’une application à observer. Cette application à observer est choisie par exemple par l’utilisateur via l’outil de configuration 21.
La phase d’enregistrement PE suivante est mise en œuvre lors de l’exécution de la composante logicielle 13.
Cette phase PE comprend notamment une étape 150 lors de laquelle le module d’enregistrement 17 filtre l’ensemble des traces générées par les fonctions instrumentées lors de la phase d’instrumentation PI.
Comme indiqué précédemment, ce filtrage est mis en œuvre en appliquant le filtre d’activation configurable de manière dynamique.
En particulier, lors de cette étape 150, l’utilisateur a la possibilité d’indiquer via l’outil de configuration 21 les critères à appliquer par le filtre d’activation.
Par exemple, le filtre d’activation peut être configuré de sorte que seules les traces générées par des fonctions instrumentées indiquées par l’utilisateur sont retenues. Les instructions d’instrumentation de ces fonctions instrumentées sont donc dites activées.
Lorsque les traces générées par une instruction d’instrumentation ne sont plus nécessaires, l’utilisateur modifie le critère correspondant du filtre d’activation et ces traces ne sont donc plus retenues par le filtre d’activation. Dans ce cas, l’instruction d’instrumentation correspondante est dite désactivée.
Dans l’exemple de la , le filtre d’activation FA retient uniquement les traces générées par l’instruction d’instrumentation « instr1 » de la fonction instrumentée F1. Les traces générées par l’instruction d’instrumentation « instr4 » de la fonction instrumentée F2 ne sont pas retenues par le filtre FA.
Lors de l’étape 160, le module d’enregistrement 17 enregistre les traces retenues par le filtre d’activation FA dans le tampon de traces 25.
Ce tampon 25 peut alors être consulté par l’utilisateur ou un logiciel adapté au cours de l’exécution de la composante logicielle 13 ou après.
Selon un exemple de réalisation, le tampon 25 présente une taille limitée de sorte que l’enregistrement de toute nouvelle trace ne se fait plus lorsque cette taille est dépassée ou se fait en écrasant les plus anciennes traces déjà enregistrées dans ce tampon 25. Dans ce dernier cas, le tampon 25 présente alors un tampon à écriture cyclique.
On conçoit alors que la présente invention présente un certain nombre d’avantages.
Tout d’abord, l’invention permet de choisir et d’instrumenter chaque fonction observable d’une composante logicielle, indépendamment de la nature de cette composante. En effet, une telle composante peut faire partie du système d’exploitation ou d’une application tierce hébergée par ce système d’exploitation.
Par ailleurs, il est possible d’adapter pour chaque fonction observable le type d’instrumentation à appliquer, éventuellement avec des paramètres différents.
Cela permet alors de rendre la solution flexible et adaptable à des différents types de logiciels et/ou de fonctions utilisables par ces logiciels.
De plus, l’utilisation des instructions neutres permet de rendre identifiables des fonctions observables sans dégradation des performances de celles-ci et si besoin, d’instrumenter celles-ci.
L’utilisation d’une zone mémoire distincte de la fonction instrumentée pour garder l’instruction d’instrumentation et éventuellement les paramètres associés, permet de réduire significativement l’influence de l’instruction d’instrumentation sur la fonction instrumentée correspondante.
Enfin, chaque instruction d’instrumentation peut être activée ou désactivée simplement en utilisant le filtre d’activation, sans avoir à supprimer l’association de cette instruction avec la fonction correspondante. De plus, cela peut être fait de manière dynamique, lors de l’exécution de la composante logicielle.
Claims (13)
- Procédé d’observation d’exécution d’une composante logicielle (13) comprenant une pluralité de fonctions, au moins certaines fonctions, dites fonctions observables, comprenant chacune un ensemble d’instructions neutres ;
le procédé comprenant une phase d’instrumentation (PI) mise en œuvre préalablement à l’exécution de la composante logicielle (13) et une phase d’enregistrement (PE) mise en œuvre lors de l’exécution de la composante logicielle (13) ;
la phase d’instrumentation (PI) comprenant les étapes suivantes :
- parmi les fonctions observables, détermination (130) de fonctions à instrumenter ;
- pour chaque fonction à instrumenter, détermination (132) d’un type d’instrumentation choisi parmi un jeu prédéterminé de types d’instrumentation ;
- instrumentation (140) de chaque fonction à instrumenter pour obtenir une fonction instrumentée, par association à cette fonction à instrumenter d’une instruction d’instrumentation correspondant au type d’instrumentation déterminé pour cette fonction ;
la phase d’enregistrement (PE) comprenant l’étape suivante :
- enregistrement (160) dans un tampon de traces (25) d’au moins certaines traces générées par au moins une instruction d’instrumentation lors de l’exécution de la fonction instrumentée associée à cette instruction d’instrumentation. - Procédé selon la revendication 1, dans lequel la phase d’enregistrement (PE) comprend en outre l’étape suivante :
- filtrage (150) des traces générées par l’ensemble des instructions d’instrumentation des fonctions instrumentées par un filtre d’activation ;
les traces enregistrées lors de l’étape d’enregistrement (160) correspondant aux traces retenues par le filtre d’activation. - Procédé selon la revendication 1 ou 2, dans lequel chaque instruction d’instrumentation est configurée pour générer des traces à l’entrée de la fonction instrumentée correspondante, ou à l’entrée et à la sortie de la fonction instrumentée correspondante.
- Procédé selon l’une quelconque des revendications précédentes, dans lequel la phase d’instrumentation (PI) comprend en outre une étape (134) de paramétrage d’au moins certaines instructions d’instrumentation, dites instructions d’instrumentation paramétrables, pour les fonctions à instrumenter correspondantes, ladite étape (134) de paramétrage comprenant la détermination de paramètres pour chaque instruction d’instrumentation paramétrable.
- Procédé selon l’une quelconque des revendications précédentes, dans lequel lors de l’étape (140) d’instrumentation, l’instruction d’instrumentation associée à au moins une fonction instrumentée est injectée dans cette fonction à la place de l’ensemble d’instructions neutres correspondant.
- Procédé selon les revendications 4 et 5, dans lequel lorsque l’instruction d’instrumentation injectée dans la fonction instrumentée correspondante est une instruction d’instrumentation paramétrable, l’étape d’instrumentation (140) comprend en outre l’injection dans cette fonction instrumentée des paramètres correspondant à cette instruction.
- Procédé selon l’une quelconque des revendications précédentes, dans lequel lors de l’étape d’instrumentation (140), l’instruction d’instrumentation associée à au moins une fonction instrumentée est injectée dans une zone mémoire distincte de cette fonction instrumentée, l’ensemble d’instructions neutres de cette fonction instrumentée étant remplacé par un branchement vers ladite zone mémoire.
- Procédé selon la revendication 7 prise en combinaison avec la revendication 5, dans lequel lorsque l’instruction d’instrumentation injectée dans ladite zone mémoire est une instruction d’instrumentation paramétrable, l’étape de l’instrumentation comprend en outre l’injection dans cette zone mémoire des paramètres correspondant à cette instruction.
- Procédé selon l’une quelconque des revendications précédentes, dans lequel chaque ensemble d’instructions neutres est injecté dans la fonction observable correspondante lors de la compilation de la composante logicielle (13).
- Procédé selon l’une quelconque des revendications précédentes, dans lequel la composante logicielle (13) est un système d’exploitation ou une application hébergée par un système d’exploitation ou une bibliothèque partagée entre plusieurs applications d’un système d’exploitation hébergeant ces applications.
- Procédé selon la revendication 10, dans lequel lorsque la composante logicielle (13) est une bibliothèque partagée entre plusieurs applications du système d’exploitation hébergeant ces applications, chaque fonction instrumentée est copiée dans un espace privé d’une application à observer lors de l’étape d’instrumentation (140).
- Produit programme d’ordinateur comportant des instructions logicielles qui, lorsqu’elles sont exécutées par un ordinateur, mettent en œuvre un procédé selon l’une quelconque des revendications précédentes.
- Système d’observation (10) d’exécution d’une composante logicielle, comprenant des moyens techniques (15, 17, 19) configurés pour mettre en œuvre le procédé selon l’une quelconque des revendications 1 à 11.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2005568A FR3110982B1 (fr) | 2020-05-27 | 2020-05-27 | Procédé d'observation d'exécution d'une composante logicielle, et produit programme d'ordinateur et système d'observation associés |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2005568 | 2020-05-27 | ||
| FR2005568A FR3110982B1 (fr) | 2020-05-27 | 2020-05-27 | Procédé d'observation d'exécution d'une composante logicielle, et produit programme d'ordinateur et système d'observation associés |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR3110982A1 true FR3110982A1 (fr) | 2021-12-03 |
| FR3110982B1 FR3110982B1 (fr) | 2022-12-02 |
Family
ID=73497820
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2005568A Active FR3110982B1 (fr) | 2020-05-27 | 2020-05-27 | Procédé d'observation d'exécution d'une composante logicielle, et produit programme d'ordinateur et système d'observation associés |
Country Status (1)
| Country | Link |
|---|---|
| FR (1) | FR3110982B1 (fr) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1997014096A1 (fr) * | 1995-10-13 | 1997-04-17 | Sevone Software, Inc. | Dispositif permettant de supprimer les defauts d'origine d'un logiciel et procede correspondant |
| US20060282710A1 (en) * | 2005-05-16 | 2006-12-14 | Texas Instruments Incorporated | Event-generating instructions |
| US20130125096A1 (en) * | 2011-08-31 | 2013-05-16 | André Kruetzfeldt | Systems and Methods for Dynamic Collection of Probe Call Sites |
| US20140229921A1 (en) * | 2013-01-30 | 2014-08-14 | Nec Laboratories America, Inc. | Method and System for Computer Assisted Hot-Tracing Mechanism |
-
2020
- 2020-05-27 FR FR2005568A patent/FR3110982B1/fr active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1997014096A1 (fr) * | 1995-10-13 | 1997-04-17 | Sevone Software, Inc. | Dispositif permettant de supprimer les defauts d'origine d'un logiciel et procede correspondant |
| US20060282710A1 (en) * | 2005-05-16 | 2006-12-14 | Texas Instruments Incorporated | Event-generating instructions |
| US20130125096A1 (en) * | 2011-08-31 | 2013-05-16 | André Kruetzfeldt | Systems and Methods for Dynamic Collection of Probe Call Sites |
| US20140229921A1 (en) * | 2013-01-30 | 2014-08-14 | Nec Laboratories America, Inc. | Method and System for Computer Assisted Hot-Tracing Mechanism |
Also Published As
| Publication number | Publication date |
|---|---|
| FR3110982B1 (fr) | 2022-12-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1788497A1 (fr) | Motif de conception et procédé de transformation d'un modèle objet | |
| FR2981174A1 (fr) | Procede de creation dynamique d'un environnement d'execution d'une application pour securiser ladite application, produit programme d'ordinateur et appareil informatique associes | |
| FR2953612A1 (fr) | Procede de mise au point d'application logicielle, systeme et produit programme d'ordinateur correspondant. | |
| EP1612668A1 (fr) | Procédé de transformation de code informatique et produit/programme d'ordinateur pour la mise en oeuvre d'un tel procédé | |
| WO2012000949A1 (fr) | Procédé de compilation sélective, dispositif et produit programme d'ordinateur correspondant | |
| EP2453356B1 (fr) | Procédé, programme d'ordinateur et dispositif de sécurisation de code intermédiaire de programmation pour son exécution par une machine virtuelle | |
| CA2194008A1 (fr) | Methode pour securiser les collaborations entre objets d'un programme oriente objet | |
| EP3625579B1 (fr) | Appareil de test et procede de test d'un circuit integre | |
| FR3110982A1 (fr) | Procédé d'observation d'exécution d'une composante logicielle, et produit programme d'ordinateur et système d'observation associés | |
| EP3182286A1 (fr) | Procede de verification de fonctionnalites d'un logiciel destine a etre embarque dans un composant cryptographique, systeme | |
| US20220413815A1 (en) | Reload ordering for executable code modules | |
| FR2986343A1 (fr) | Procede de pre-compilation, procede de compilation, programme d'ordinateur et systeme informatique | |
| EP0678811A1 (fr) | Procédé de détection d'interblocages dans les systèmes multiprocesseurs à mémoire partagée | |
| WO2021130420A1 (fr) | Procédé et dispositif mettant en œuvre ce procédé pour générer et installer un code exécutable dans la mémoire d'un noyau d'une machine virtuelle depuis un hyperviseur | |
| FR3046476A1 (fr) | Procede de conversion des mecanismes d'allocation dynamique de memoire d'un code source initial d'un logiciel | |
| FR2957434A1 (fr) | Dispositif de test d'une architecture de calcul multitaches et procede de test correspondant | |
| EP3195113B1 (fr) | Procédé de vérification de traçabilité de premières instructions en un langage de programmation procédurale générées à partir de secondes instructions en un langage de modélisation | |
| FR3035984A1 (fr) | Procede de detection d'un logiciel malveillant | |
| FR3029658A1 (fr) | Systeme et methode de gestion de code octal java | |
| FR3042291A1 (fr) | Dispositif et procede de verification d'un logiciel | |
| FR2938087A1 (fr) | Procede d'implementation d'une machine a etats finis via l'utilisation d'annotations java. | |
| FR3026511A1 (fr) | Procede de test d'un composant logiciel | |
| FR3101973A1 (fr) | Dispositif de surveillance | |
| FR3131032A1 (fr) | Procédé de génération d’un fichier exécutable contenant des appels systèmes et librairie associée. | |
| EP1387270B1 (fr) | Procédé et système de reconnaissance automatique de configurations de simulations d'un circuit intégré |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20211203 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |
|
| PLFP | Fee payment |
Year of fee payment: 4 |