Rim Chaabane. Analyse dynamique de ... - Université Paris 8

Rapport de stage de DEA Intelligence Artificielle
et Optimisation Combinatoire
Au Laboratoire d Intelligence Artificielle de
l Université de Vincennes Paris 8
Réalisé par :
Encadré par :
Mlle CHAABANE Rim
Mme BALMAS Françoise
Année universitaire
2004-2005

Remerciements
Je remercie en premier lieu ma mère, Dorra, Sami, Manu et Samia ainsi que ses filles,
pour leur soutien, leurs encouragements constants tout au long de cette année de DEA. Je
remercie énormément Madame Balmas qui m a soutenu et suivi avec grande attention. Je la
remercie également pour ses encouragements, sa confiance et sa précieuse aide et j espère avoir
été à la hauteur de ses attentes et de sa confiance.
Je remercie mon amie Samia pour ses encouragements et pour son aide dans la relecture du
présent mémoire.
Je salue mes camarades de promotion avec qui j ai passé d agréables et mémorables moments. Je
les remercie aussi pour leurs encouragements, leurs conseils et leur aide.
Je remercie finalement l ensemble des professeurs des universités Paris 8 et Paris 13 pour les
enseignements qu ils nous ont transmis, ainsi que de leurs précieux conseils pour notre éventuelle
future carrière dans le domaine de la recherche.

Résumé
Ce sujet se place dans le cadre de l aide aux développeurs dans leur travail de maintenance
de programmes. En effet, il arrive souvent que des développeurs aient à travailler sur de longs
codes sources qui ont été développés par d autres personnes. Il est donc peu aisé de suivre le
fonctionnement des appels de fonctions et des variations des variables pendant leur exécution.
Le projet d A nalyse dynamique de programmes a pour objectif de permettre au développeur de
visualiser graphiquement les changements pendant l exécution du programme à maintenir et de
visualiser les appels de fonctions ainsi que d autres informations. Pour cela, les dépendances de
données dynamiques sont collectées pendant l exécution des programmes, stockées dans une
base de données, puis affichées sous forme de graphes.
Le projet a déjà été réalisé pour analyser des codes sources en Lisp [BAL 05], le travail effectué
dans ce projet consiste à reproduire cette même analyse pour des programmes sources C. Pour
effectuer cela, nous avons dû modifier un interprète C pour l extraction dynamique des données
et traiter ces données pour pouvoir visualiser graphiquement leurs dépendances.

Sommaire
CHAPITRE 1 - INTRODUCTION.................................................................................................................... 9
1.1. QU EST-CE QUE L ANALYSE DE PROGRAMMES ?................................................................................ 9
1.2. OBJECTIFS DU PROJET D ANALYSE DYNAMIQUE DE PROGRAMMES C............................................. 10
1.2.1. Créer un outil d analyse de programmes C fiable et évolutif........................................................ 10
1.2.2. Un affichage clair des dépendances de données ........................................................................... 11
1.3. PRESENTATION DE L OUTIL D ANALYSE DE PROGRAMMES C.......................................................... 11
CHAPITRE 2 - APPROCHE DE LA PROBLEMATIQUE ET CHOIX DE LA SOLUTION................... 17
2.1. COMMENT EXTRAIRE DYNAMIQUEMENT LES DONNEES D UN PROGRAMME SOURCE EN LANGAGE
C .. 17
2.1.1. Les étapes de la compilation de GCC............................................................................................ 17
2.1.2. Le choix d une solution.................................................................................................................. 19
2.2. QUELLES DONNEES EXTRAIRE ? ....................................................................................................... 19
2.3. LA REPRESENTATION GRAPHIQUE .................................................................................................... 20
CHAPITRE 3 - LES INTERPRETES C EXISTANTS................................................................................... 24
3.1. UNDERC............................................................................................................................................. 25
3.2. CINT ................................................................................................................................................... 26
3.3. JFL C................................................................................................................................................. 28
3.4. EIC..................................................................................................................................................... 29
3.5. CH ...................................................................................................................................................... 31
3.6. POURQUOI EIC ? ............................................................................................................................... 34
CHAPITRE 4 - EXPLORATION DE L INTERPRETE EIC........................................................................ 34
4.1. SPECIFICITES DE EIC ........................................................................................................................ 36
4.1.1. Installation et compilation............................................................................................................. 36
4.1.2. Les modes d exécution de l Interprète EiC.................................................................................... 36
4.1.2.1. Le mode interactif................................................................................................................................36
4.1.2.2. Le mode batch......................................................................................................................................37
4.1.3. Les différences entre EiC et C ....................................................................................................... 39
4.2. STRUCTURE DE FICHIERS .................................................................................................................. 41
CHAPITRE 5 - DESCRIPTION TECHNIQUE DU TRAVAIL REALISE ................................................. 43
5.1. EXTRACTION DYNAMIQUE DES DONNEES ......................................................................................... 43
5.1.1. Description de la procédure d extraction...................................................................................... 45
5.1.2. Modifications apportées à EiC ...................................................................................................... 45
5.1.2.1. Identification des variables dans EiC...................................................................................................49
5.1.2.2. Enregistrement de la dernière ligne utilisant une variable ...................................................................49
5.1.3. Numérotation et compteur d appel des instructions...................................................................... 50
5.1.4. Extensions pour les boucles et l appel de fonctions ...................................................................... 54
5.2. AFFICHAGE DU GRAPHIQUE DE DEPENDANCES ENTRE DONNEES..................................................... 55
5.2.1. L outil dot ...................................................................................................................................... 55
5.2.2. Formatage de la base de données au format dot........................................................................... 56
CHAPITRE 6 - EXEMPLES DE RESULTATS.............................................................................................. 59
6.1. OPERATIONS SUR DES VARIABLES ENTIERES.................................................................................... 59
6.2. CONDITIONNELLES............................................................................................................................ 60

6.2.1. L instruction if............................................................................................................................... 60
6.2.1.1. Cas simples ..........................................................................................................................................60
6.2.1.2. If imbriqués..........................................................................................................................................61
6.2.2. Boucle while .................................................................................................................................. 62
6.2.3. Boucle do while ............................................................................................................................. 64
6.2.4. Boucle for ...................................................................................................................................... 64
6.2.5. Boucles imbriquées........................................................................................................................ 66
6.3. APPELS DE FONCTIONS AVEC ET SANS ARGUMENTS......................................................................... 67
6.3.1. Fonction sans arguments............................................................................................................. 676
6.3.2. Fonction avec arguments............................................................................................................... 68
CHAPITRE 7 - COMPARAISON AVEC L EXISTANT............................................................................... 69
7.1. CALL GRAPH DRAWING INTERFACE ................................................................................................. 69
7.2. ZEUGMA : REPRESENTATION METAPHORIQUE DE PROGRAMMES ................................................... 70
7.3. CARE ................................................................................................................................................ 72
CHAPITRE 8 - CONCLUSION ET PERSPECTIVES .................................................................................. 76
8.1. LIMITES DE NOTRE OUTIL D ANALYSE DYNAMIQUE DE PROGRAMMES C ....................................... 77
8.2. AMELIORATIONS POSSIBLES ............................................................................................................. 77
8.2.1. Prise en charge des spécificités du langage C............................................................................... 77
8.2.2. La numérotation des instructions et le format de la base de données ........................................... 78
8.2.3. La représentation graphique ......................................................................................................... 79
8.2.4. Vers un outil complet d analyse dynamique .................................................................................. 79
ANNEXES............................................................................................................................................................ 85
ANNEXE - I - PROGRAMMES DE TESTS DES INTERPRETES C ET TRACES DE TESTS ....................................... 88
ANNEXE - II - COMMANDES INTERNES A EIC EN MODE INTERACTIF............................................................ 91
ANNEXE - III - DIRECTIVES D APPEL A EIC EN MODE BATCH ....................................................................... 93
ANNEXE - IV - SCRIPT SHELL "EIC_ADPC.SH ............................................................................................... 95
ANNEXE - V - SCRIPTS AWK............................................................................................................................ 98
ANNEXE - VI - EXTRAITS DU CODE SOURCE MODIFIE DE EIC ....................................................................... 99

Analyse dynamique de programmes C
Chapitre 1 - Introduction
Ce projet d analyse dynamique de programmes C, se place dans le cadre de travaux de recherches
sur l analyse de programmes. Ces travaux ont pour but de faciliter la compréhension de
programmes, d aider les développeurs tenus de maintenir des programmes à cerner plus
facilement les actions effectuées par ces derniers et de leur éviter la lecture exhaustive des très
nombreuses lignes de codes pouvant composer un programme.
Avant de détailler les objectifs de ce projet, nous commençons par expliquer qu est ce que
l analyse de programmes, et les différentes techniques d analyses existant à l heure actuelle. Dans
la deuxième section, nous définissons les objectifs du projet d analyse dynamique de programmes
C. La dernière section donne un aperçu rapide des capacités de notre outil d analyse dynamique
de programmes C.
1.1. Qu est-ce que l analyse de programmes ?
L analyse de programmes est un domaine de recherche qui s est développé dans le but de
comprendre assez rapidement les propriétés des programmes de plus en plus complexes, et dont
la maintenance devient fastidieuse. En effet, il devient nécessaire de mécaniser la procédure de
maintenance d un programme ou du moins d en faciliter la tâche, d autant plus que cette tâche est
la plus coûteuse dans le cycle de production d un logiciel. Des études ont d ailleurs montré que
20% du coût de production est généré lors de la phase de développement, 40% lors de la phase
de débuggage et 40% lors de la phase d ajout de nouvelles fonctionnalités [HAT 97, JAH 00]. Il
est donc évident que 80% des dépenses se font lors de la phase de correction-maintenance d un
logiciel. Ceci explique l importance pour les industries de réduire leurs dépenses pour la
maintenance d un programme.
Un analyseur de programmes est alors une aide précieuse pour le développeur, car il lui permet de
comprendre plus facilement ce que fait un programme, en particulier dans le cas où ce dernier fut
développé plusieurs années en arrière et/ ou par différents programmeurs. Un analyseur permet
également de détecter plus facilement des erreurs ou des instructions consommatrices en
ressources systèmes, ce qui favorise alors un débuggage et une optimisation de code plus rapides.
Voici une liste possible d utilisation des résultats d outils d analyse [LAN 05] :
Les analyses de flots de données permettent de détecter notamment les variables inutiles
ou les expressions calculées à un point de programme donné.
Les analyses d'alias produisent des informations sur le partage entre variables dans les
langages à manipulation explicite de pointeurs.
Le filtrage de programmes (slicing) consiste à identifier les instructions d'un programme
nécessaires au calcul de variables données.
Le débuggage est une analyse dynamique de programmes interactive, qui permet à
l utilisateur de spécifier «à la volée » les informations et propriétés qu il désire voir sur
l exécution en cours.
9

Chapitre 1 - Introduction
Le monitoring d exécutions est une analyse dynamique de programmes non interactive.
Le profileur est un moniteur permettant d avoir des informations relatives au temps
d exécution des différents composants du programme.
Il existe principalement deux classes d'analyses : les analyses dynamiques et les analyses statiques.
L'analyse dynamique déduit des propriétés d'un programme à partir d'une trace d'exécution
particulière. D un point de vue pratique l analyse dynamique s avère d une plus grande aide aux
développeurs. Elle permet de fournir les valeurs des données manipulées lors de l exécution du
programme ainsi que l enchaînement des étapes d exécution des diverses instructions appelées. Il
faut également noter que la précision des informations fournies avec ce type d analyse entraîne la
génération d une masse de données, ce qui relève les questions de représentation graphique et
éventuellement dans certains cas de stockage.
Contrairement à cette analyse dynamique, l analyse statique se contente de lire le programme en
prenant en compte toutes les possibilités d exécutions. Ainsi, l'analyse statique permet d'établir
des propriétés satisfaites par un programme pour toutes ses exécutions et s avère utile pour
comprendre toutes les possibilités d un programme et pour en voir les limites. L'information
recherchée est en général incalculable ou d'une complexité importante, ce qui implique le fait que
l analyse statique ne peut calculer qu'une approximation de la solution idéale.
En conséquence, les résultats de l'analyse statique sont moins précis mais plus généraux que ceux
fournis par une analyse dynamique. C est pour cette raison que des outils basés sur une analyse
dynamique, tels que les moniteurs, les profileurs et les débuggeurs sont nécessaires pour
maintenir ou même développer un programme.
1.2. Objectifs du projet d analyse dynamique de
programmes C
1.2.1. Créer un outil d analyse de programmes C fiable et
évolutif
Un prototype d outil d analyse dynamique de programme, DDFgraph, a déjà été développé par
l équipe de recherche du laboratoire d Intelligence Artificielle de l université de Vincennes (paris 8)
par Françoise Balmas et Harald Wertz, pour le langage Lisp [BAL 05]. Le langage Lisp étant un
langage interprété, il y a donc la possibilité de modifier l interprète Lisp afin d en extraire des
informations sur l exécution du programme. Ces informations sont par la suite exploitées pour
générer le graphe de dépendances des différentes interactions entre variables, pointeurs ou encore
fonctions du programme source. L objectif du présent projet consiste à reproduire le même
schéma d analyse de DDFgraph, mais en l adaptant au langage C qui est un langage compilé
contrairement au Lisp.
10

Chapitre 1 - Introduction
1.2.2. Un affichage clair des dépendances de données
Le deuxième objectif de ce projet est de pouvoir donner une représentation graphique claire et
bien structurée des dépendances existant entre les données extraites. Il se trouve qu il n est pas
aisé de trouver la bonne représentation des relations entre les données utilisées, du fait que
chaque langage a ses propres spécificités.
Par exemple, le langage C donne la possibilité de manipuler des tableaux contrairement au
langage Lisp qui n utilise pas ce type de représentations. Il faut alors imaginer une forme de
représentation graphique montrant les modifications effectuées lors de l exécution du programme
sur le tableau. Il faut également que cette dernière soit assez claire pour être comprise du
développeur de manière presque intuitive. L étude des représentations possibles est faite dans la
section 2.3 du prochain chapitre.
1.3. Présentation de l outil d analyse de
programmes C
Le projet d analyse dynamique de programmes écrits en C à pour ambition d adapter l outil
DDFgraph de [BAL 05] au langage C, car ce langage, bien qu ancien (crée en 1972 par Denis
Ritchie), est cependant utilisé de manière plus importante que le langage Lisp.
L outil d analyse de programmes C, réalisé dans le cadre de ce projet de DEA, offre des
possibilités d évolution de par sa base de conception. En effet, cet outil repose sur un interprète
C modifié à notre convenance. Cette solution présente l avantage de pouvoir améliorer les
performances de l outil sans trop d efforts pour comprendre son fonctionnement contrairement à
ce que cela pourrait être avec le compilateur GCC. Il permet actuellement de gérer les boucles, les
structures de contrôle mais uniquement des objets de type entier tels que des variables, des
fonctions, ou encore des tableaux (cf. chapitre 5). Ceci peut être facilement étendu aux autres
types en copiant la technique utilisée pour les types entiers et en l adaptant aux autres.
Notre outil se doit d être une reproduction de l outil DDFgraph d analyse de programmes Lisp,
pour le langage C. Pour comprendre le concept d analyse dynamique de ces deux outils, je vais
donner un exemple d utilisation de notre outil sur un simple programme C et présenter ce qu on
entend par graphique de dépendances entre données. Puis pour comprendre l utilité de notre
outil à terme je présente un exemple de résultat obtenu grâce à l outil DDFgraph. Cet exemple
permettra de voir comment l outil d analyse dynamique de programme peut mettre en évidence le
disfonctionnement d un programme bien que le résultat retourné soit visiblement correct.
Il semble important à ce stade d avoir une idée concrète de ce qu est une représentation
graphique des dépendances entre données, pour pouvoir aborder la suite du mémoire. Pour cela,
nous présentons le résultat obtenu par notre outil pour un programme C qui effectue de simples
opérations sur des variables, le contenu du fichier de code source utilisé « ext_affvar.c » est listé cidessous.
1
2 /*
3 ext_affvar.c
11

Analyse dynamique de programmes C
4 */
5
6
7 int m;
8
9 int main()
10 {
11 int x,y,a,b,c;
12
13 x = 12;
14 y = 8;
15 m = 15;
16 a = x + y;
17 b = x - y;
18 c = a + b;
19 return c;
20 }
::EiC:: : 5 -> [main]
13.-
Def 1-0 12 13
14.-
Def 1-1 8 14
15.-
Def 0-2 15 15
16.-
Use 1-0 13 16
Use 1-1 14 16
Def 1-2 20 16
17.-
Use 1-0 13 17
Use 1-1 14 17
Def 1-3 4 17
18.-
Use 1-2 16 18
Use 1-3 17 18
Def 1-4 24 18
19.-
Use 1-4 18 19
Notre outil a extrait de l exécution de ce programme l ensemble des informations manipulées, à
savoir les variables définies et leurs valeurs. On peut voir à la suite du code source le format des
données extraites, on peut y distinguer deux types d informations : Use var l1 l2 et Def var val L.
Quand on a Use var l1 l2 cela signifie que l instruction de la ligne l2 utilise la variable var
définie en ligne l1, et quand on a Def var val L cela signifie que l instruction de la ligne L définit
la variable var avec la valeur val. Prenons par exemple l instruction de la ligne 16 du
programme, dans laquelle on affecte à la variable a la somme des valeurs de x et y. Dans les
données extraites on peut voir pour l instruction 16 (surlignée en bleu) les informations suivantes :
- Use 1-0 13 16, signifie que l instruction de la ligne 16 utilise la variable nommée « 1-
0 » (qui correspond à x) 1 définie auparavant à la ligne 13 du code source (cf. définition
mise en évidence dans les informations extraites par le surlignage orange).
- Use 1-1 14 16, signifie que l instruction de la ligne 16 utilise la variable nommée « 1-
1 » (qui correspond à y) définie auparavant à la ligne 14 du code source (cf. définition
mise en évidence dans les informations extraites par le surlignage jaune).
- Def 1-2 20 16, signifie que l instruction de la ligne 16 définit la variable « 1-2 », c est-àdire
a, avec la valeur 20, somme de 12 pour x et 8 pour y.
Ainsi, le format de données extraites aussi appelé base de données, est assez abstrait et n est donc
pas adapté pour une lecture humaine. En effet, ce format est conçu de manière à décomposer le
code source pour mettre en évidence les dépendances entre ses données (ici variables), que nous
transformons ensuite en un graphe donné en figure 1, il devrait à terme donner le résultat de la
figure 2.
1 Les variables sont désignées actuellement par des identifiants (comme ils sont distingués dans l interprète) en
attendant que la correspondance avec la table des symboles soit faite afin de récupérer leur nom.
12

Chapitre 1 - Introduction
1-0 = 12 1-1 = 8
0-2 = 15
1-2 = 20
1-3 = 4
1-4 = 24
Figure 2. Graphique mettant en évidence
les dépendances entre les données
manipulées par le programme
« ext_affvar.c »
Figure 2. Même graphique qu en figure 1
avec les identifiants de variables
remplacés par leurs symboles.
Sur la figure 2, on peut voir les dépendances entre les variables du programme de notre exemple
et les lignes qui les référencent. Les lignes d instructions sont représentées par des n uds de
couleur noire avec le numéro de ligne inscrit à leur centre, les variables sont représentées par des
n uds de couleur verte avec le nom de la variable et sa valeur inscrites à leur centre. Reprenons la
ligne 16 du code source, sur le graphique de la figure 2 on peut voir deux flèches dirigées vers le
n ud 16 et partant chacune des variables x et y dont les valeurs respectives sont égales à 12 et 8.
Le n ud 16 renvoie une flèche sur la variable a dont la valeur devient égale à 20.
Comme on peut le voir sur cet exemple, le graphe de dépendance entre données nous permet de
voir assez facilement les liens entre les données du programmes, cette visualisation peut mettre en
évidence des variables définies mais non utilisées comme le montre également notre exemple
pour la variable m qui est visuellement isolée des autres n uds, ce qui signifie qu elle n a pas été
utilisée dans le code source.
Les travaux de [BAL 05] ont montré l intérêt de la représentation graphique des dépendances
dynamiques pour la compréhension de programmes. Elle permet notamment de montrer le
fonctionnement général d un programme 2 , de suivre ses appels de fonctions, de détecter
d éventuelles erreurs de conceptions ou encore de vérifier le comportement du programme. C est
ce que nous montrons dans l exemple suivant où DDFgraph gère une version Lisp du
programme Blocks Word classique de l Intelligence Artificielle [WIN 72], qui permet de
manipuler des objets sur une table. Dans la figure 3, la visualisation des valeurs des variables
globales (en gris foncé dans le graphe) montre l effet du programme : la boite a est mémorisée
2 Pour cela le graphe de dépendances est compacté (cf. figure 3) de manière à montrer uniquement les valeurs
connues en entrée et en sortie.
13

avec un ensemble de propriétés qui vont ensuite permettre au programme de la manipuler
correctement.
Figure 3. Graphique condensé d'un programme d'IA qui place un objet sur une table
Figure 4. Exemple d'utilisation de DDFgraph mettant en évidence une erreur d'exécution
Sur la figure 4, on peut voir le fonctionnement de ce même programme qui place un objet de
type boite de dimension 2*2 sur une table de dimension 4*4 (la table et les objets sont
représentés comme des matrices). L objet est déposé sur la table en position 1-1 (cf. R-
trouvePlaceSur = ( 1 1) ). Vu les dimensions de l objet il sera ainsi placé sur les positions 1-1, 1-2,
2-1 et 2-2 ce qui est correct, puisque la table était initialement vide. Mais en regardant en détail le
comportement de la fonction trouvePlaceSur, on remarque que cette dernière vérifie
uniquement la disponibilité des positions 1-1, 1-2, et 2-1 sur la table (soulignés en rouge sur la
14

Chapitre 1 - Introduction
figure) et la vérification de la dernière position 2-2 est ignorée. Cela traduit donc un
disfonctionnement du programme, bien que ce dernier donne un bon résultat au final.
Après cet aperçu rapide des possibilités de l outil d analyse de programmes, nous traitons dans le
chapitre qui suit des problématiques résultant de l analyse dynamique de programmes en langage
C et de la génération de graphiques de dépendances. Dans ce même chapitre nous décrivons les
solutions choisies pour chacune des problématiques. Dans le chapitre 3 nous comparons les
interprètes qui nous étaient accessibles et donnons les raisons pour lesquelles notre choix s est
porté sur l interprète EiC. Les spécificités de cet interprète sont détaillées dans le chapitre 4 qui
décrit également les différences entre EiC et le langage C, une description de la structure de ses
fichiers sources est également faite dans ce chapitre afin de mieux introduire dans la chapitre 5 les
modifications que nous avons apportées à EiC et les techniques utilisées pour générer le
graphique de dépendance de données. Le chapitre 6 présente plusieurs graphes générés par notre
outil. Le chapitre 7 donne un aperçu des études dans le domaine de l analyse dynamique et dans
celui de la représentation graphique de programmes. Le chapitre 8 conclu ce mémoire avec une
présentation des principales perspectives.
15

Analyse dynamique de programmes C
Chapitre 2 - Approche de la
problématique et choix de la
solution
Le projet d analyse dynamique de programmes C pose de nombreux problèmes. En effet,
les spécificités du langage C par comparaison au Lisp 3 , nous amènent à nous demander comment
extraire de manière dynamique les données manipulées par le programme source et plus
particulièrement à quel niveau de transformation du programme cela pourrait se faire. De même,
il faut déterminer quels sont les types de données à extraire du programme afin d apporter au
développeur une analyse fiable et précise. Enfin, il faut choisir de quelle manière représenter
graphiquement l ensemble de ces informations de manière à avoir une vision claire du
déroulement d un programme.
La section 2.1 ci-dessous traite de la question de la spécificité du langage C, et présente la solution
choisie pour ce projet. La section suivante 2.2, traite quant à elle du type des données à extraire.
La dernière section 2.3, expose la manière dont les informations extraites sont représentées et la
technique mise en place pour le réaliser.
2.1. Comment extraire dynamiquement les
données d un programme source en langage
C ?
Comme nous l avons dit dans le premier chapitre, le projet d analyse dynamique de programme a
déjà été réalisé pour des programmes écrits en langage Lisp. Ce langage est un langage interprété,
c'est-à-dire que l exécution du programme se résume à un cycle de lecture des instructions, ligne
par ligne, puis de leur évaluation. Pour analyser des programmes écrits en Lisp il suffit donc de
modifier l interprète Lisp même, afin de lui permettre de générer, pendant la lecture et l exécution
des instructions, les données relatives au code à analyser.
Par contre, le langage C est un langage compilé, c'est-à-dire qu exécuter un code source C revient
à le transformer d abord en un programme exécutable (binaire). Les étapes de la compilation sont
décrites plus en détail ci-dessous.
2.1.1. Les étapes de la compilation de GCC
La transformation d un programme C en binaire se déroule en deux étapes indépendantes : le
prétraitement et la compilation proprement dite.
3
Notamment le fait qu il soit compilé plutôt qu interprété.
17

Chapitre 2
Approche de la problématique et choix de la solution
L étape de prétraitement correspond à une modification du texte d un fichier source, basée
essentiellement sur l interprétation d instructions très particulières dites directives à destination du
préprocesseur ; ces dernières sont reconnaissables par le fait qu elles commencent par le symbole
#. Par exemple l instruction #include permet au programme source d utiliser des fonctions des
librairies standards ou d autres fichiers de code (« headers » d extension .h).
L étape de compilation consiste à traduire les fichiers sources en langage machine, le résultat de
cette opération portera le nom de «module objet ». Après assemblage des différents modules, un
éditeur de lien réunit les modules objets et les fonctions de la bibliothèque standard pour
constituer un programme exécutable par la machine.
Sans rentrer plus en détail dans le fonctionnement d un compilateur C on peut voir sur la figure 5
un schéma de la compilation [GRU 00] qui résume son cycle jusqu à la génération du fichier
exécutable.
Lecture du texte
du programme
Optimisation du
CI
caractères
CI
Analyse lexicale
lexèmes
Génération de
code
Instructions symboliques
Fichier
souce
Analyse
syntaxique
arbre abstrait
Code
intermédiaire
Optimisation du
code cible
Instr. symboliques
Fichier
exécutable
Analyse
sémantique
Génération de
code machine
arbre décoré
Suite de bits
Génération du
code intermédiaire
Sortie du code
exécutable
Partie avant
Compilateur
Partie arrière
Figure 5. Structure d'un compilateur
Dans la section suivante nous étudions à quelle(s) étape(s) de la transformation on peut obtenir
les informations sur notre programme source donné en entrée.
18

Chapitre 2
Approche de la problématique et choix de la solution
2.1.2. Le choix d une solution
Maintenant que nous avons vu la structure d un compilateur C et sachant que le code binaire qu il
génère est uniquement destiné à la machine, il semble évident que le programme exécutable en
fin de transformation ne peut nous être utile pour notre travail. Une première solution possible
est de modifier le compilateur GCC 4 , en y intégrant le code nécessaire à l obtention
d informations dynamiques, code qui sera activé pendant l exécution du programme binaire. Ceci
nous permettrait d inclure en code compilé les instructions nécessaires à la génération des
informations dynamiques. Cette solution, bien que réalisable, n est pas retenue dans notre projet
car elle demande une connaissance assez poussée du compilateur GCC, difficile à acquérir
pendant la durée du projet, d autant plus qu une autre solution plus simple était possible. En effet
il existe des interprètes du langage C, qui permettent d exécuter instruction par instruction chaque
fichier source. On peut voir sur le schéma de la figure 7 la différence existant entre un
compilateur et un interprète [GRU 00].
Code
source
Code
intermédiaire
Machine
prétraitement
Compilation
traitement
Code
source
Code
intermédiaire
Interprète
prétraitement
traitement
Interprétation
Figure 6. Comparaison entre un compilateur et un interprète
L avantage ici est que la taille du code source d un interprète est beaucoup moins importante que
celle du compilateur GCC. Il est donc plus facile à étudier et par conséquent ses fonctionnalités
sont plus simples à modifier. De plus, l approche à suivre est similaire à l approche suivie pour
l interprète Lisp.
La problématique due à la complexité du compilateur du langage C est de cette manière écartée, il
nous reste donc plus qu à trouver un interprète C, assez bien conçu, parmi ceux existant dans
l univers du logiciel libre. L ensemble des interprètes trouvés sont présentés et comparés dans le
chapitre 3.
2.2. Quelles données extraire ?
Dans cette section nous réfléchissons sur le type de données à extraire d un fichier source C, ce
qui représente une autre problématique à ce projet. Qui consiste à savoir quelles sont les données
4
Plus précisément l option p du profileur de GCC.
19

Chapitre 2
Approche de la problématique et choix de la solution
que nous pouvons extraire lors de l exécution d un programme et ceci sans avoir à modifier le
code source à analyser.
En se basant sur les travaux réalisés au laboratoire d Intelligence Artificielle de l Université Paris 8
concernant la compréhension de programmes, qui consistent à interroger des programmeurs sur
leurs méthodes pour lire et comprendre un fichier source [BAL 00], un nombre d informations se
sont avérées intéressantes à tracer :
- Les modifications des valeurs de variables (locales ou globales)
- Les noms de fonctions appelées, leurs arguments et les valeurs de ces dernières tout au
long de l exécution du programme
- L interaction entre les fichiers sources.
En effet, la trace de ces types d informations permet au programmeur d optimiser son code en
détectant les variables déclarées mais non utilisées ou encore en détectant des erreurs de
conception du programme, qui font que le programme compile sans aucune erreur mais ne
donne pas le résultat attendu. De même, tracer le passage dans les boucles for/ while/ do permet de
détecter les boucles sans fin, voire les boucles inutiles.
Dans le cadre de ce projet, l ensemble des informations que nous avons choisi d extraire est :
- Les variables et leurs valeurs
- Les fonctions et leurs arguments
- Les tableaux à une dimension
- Les conditions et leur valeur (vraie ou fausse)
- L emplacement dans le code source (fichier, numéro de ligne)
- Le nombre d appel d une instruction
En effet les deux dernières informations vont nous permettre de savoir de quelle ligne du code
vient la valeur d une variable utilisée, l utilité de ces dernières données est détaillé au chapitre 5.
A terme, nous envisageons d extraire les appels récursifs de fonctions, le passage d un pointeur
ou d un tableau en argument d une fonction, et d autres particularités du langage C. Mais le
principal objectif dans ce projet est de représenter graphiquement dans un premier temps les
informations listées plus haut. On pourra dans des travaux futurs étendre cette technique à
l ensemble des données manipulées lors de l exécution d un programme C (cf. chapitre 8).
2.3. La représentation graphique
Cette section présente une autre problématique de notre projet d analyse dynamique de
programmes C qui survient une fois que les données sont extraites. En effet, l extraction des
données du programme en cours d exécution nous amène à nous interroger sur la manière de
représenter graphiquement ces informations de manière dynamique. Une réflexion a déjà été
menée pour la représentation des interactions entre données extraites de programmes Lisp [BAL
01]. Cette réflexion a conduit à représenter les données telle que l appel à une fonction de la
manière suivante pour le langage Lisp :
Soit le code source de la fonction som2(x y) qui effectue la somme des carrés de deux
nombres, listé ci-dessous dans les lignes 1 à 4.
1. (de square (a)
2. (* a a))
3. (de som2 (x y)
4. (+ (square x) (square y)))
20

Chapitre 2
Approche de la problématique et choix de la solution
5. ?
6. ? (som2 3 5)
7. = 34
Sur la figure 8 on peut visualiser le graphique correspondant à l appel de (som2 3 5) (cf. ligne
6), avec le détail de toutes les relations entre les fonctions et variables utilisées par le programme.
Figure 7. Graphe de dépendance pour (som2 3 5) avec toutes les dépendances
En effet, l outil DDFgraph permet de gérer non seulement l affichage des interactions entre
variables mais également l affichage des appels entre fonctions. Les variables sont représentées
par des n uds ovales colorés contenant le nom de la variable et sa valeur, les fonctions sont
représentées par des rectangles noirs contenant le nom de la fonction. Si une fonction renvoie un
résultat, ce dernier est représenté comme une variable dont le nom est le nom de la fonction
précédé d un R-. Par exemple, la fonction som2 fait appel à la fonction square pour ses deux
arguments : 3 et 5. Le résultat renvoyé par l appel à som2 est également visible sur le graphique
R-som2 = 34.
Contrairement à la figure 7 où tous les appels effectués sont représentés, la figure 8 présente ce
même graphe de dépendances sous forme condensée, c est-à-dire que seules les entrées/sorties
de la fonction som2 sont visibles et que les appels internes à cette fonction sont cachés. Grâce à
l interface graphique de l outil DDFgraph, de simples manipulations à la souris permettent de
passer d une représentation à une autre.
21

Chapitre 2
Approche de la problématique et choix de la solution
Figure 8. Graphe de dépendances de l'appel de (som2 3 5) avec affichage des appels globaux
Il existe d autres types de représentations graphiques pouvant être générées par DDFgraph,
comme l affichage sélectif des appels dans un programme ainsi que d autres représentations
toujours interactives permettant au développeur de manipuler le graphique à sa guise.
Pour notre outil, nous tâchons de traiter des choses simples pour le moment tout en suivant les
définitions de représentation des données par DDFgraph. A savoir, les variables seront
représentées par des ellipses et les fonctions par des rectangles, les identificateurs de boucles
(for, while, do) ainsi que les structures de contrôle (if/ else) seront représentés par des
losanges dont les liens partent du sommet droit si la condition est vraie et du gauche sinon. Nous
pouvons voir un exemple de cette représentation graphique ci-dessous :
main
X=2
Vrai
if
(x>=1)
Faux
exit
La manière dont sont générés les graphiques de dépendances dynamiques de données est détaillée
dans le chapitre 5. Le chapitre qui suit décrit les différents interprètes C et explique notre choix
d interprète.
22

Chapitre 2
Approche de la problématique et choix de la solution
23

Analyse dynamique de programmes C
Chapitre 3 - Les interprètes C existants
Comme il a été expliqué dans la section 2.1, l extraction des informations d un programme
C en cours d exécution est faite à l aide d un interprète et non pas du compilateur GCC. Il existe
un certain nombre d interprètes du domaine public pour le langage C, dont l utilisation est
principalement orientée pour l apprentissage du langage C. En effet, la particularité d un
interprète de permettre à l utilisateur de visualiser le résultat de chaque instruction après son
exécution, aide les débutants en langage C d en comprendre le fonctionnement plus aisément.
Ce chapitre présente ces interprètes C, les compare, et discute des tests effectués sur ceux qui
sont le plus susceptibles de nous aider à la réalisation du travail d analyse dynamique des
programmes C. Les principaux critères requis pour l interprète recherché sont :
- Interpréter le langage C dans toutes ses spécificités (librairies standard du C, pointeurs,
structures, récursivité, etc )
- Disponibilité du code source
- Traitement d un programme source faisant appel à plusieurs fichiers (headers et autres
fichiers source .c)
- Prise en charge de programmes C avec un grand nombre de lignes de codes
- Éventuellement un débuggeur intégré
On peut voir dans le tableau ci-dessous un rapide aperçu de ces critères pour l ensemble des
interprètes C trouvés :
Interprètes
Langage
Supporte toute
la librairie
standard C ?
Licence
Code source
accessible ?
Débuggeur
intégré ?
UnderC C++/C Non GPL 5 Oui Non
Cint C++/C Non GPL Oui Non
JFL C Mini C Non Payant Non Non
EiC C Oui GPL Oui Oui
Ch C/C++/Ch/Shell Oui GPL Non Non
Figure 9. Tableau récapitulatif des propriétés des interprètes C
Les sous-sections qui suivent décrivent en détail chacun de ces interprètes, avec leurs avantages et
leurs inconvénients. Les interprètes proches des critères exposés plus haut sont testés pour en
voir les limites. Dans la dernière sous-section, j explique mon choix d interprète pour réaliser le
travail d analyse dynamique, en fonction des critères des interprètes trouvés et des résultats de
leur test.
5 General Public Licence
24

Chapitre 3
Les interprètes C existants
3.1. UnderC
Cet outil est un interprète plus particulièrement orienté pour le langage C++, développé par
Steve Donovan en 2001 et dont la dernière version date de 2003 [DON 02]. L auteur décrit
UnderC comme un interprète compact de C++ (« A compact C++ interpreter »), mais il est capable
également d interpréter des programmes C. En effet, il utilise des librairies standard C construites
autour de GCC 2.95, ce qui lui confère la capacité de supporter la syntaxe des langages C++ et C.
UnderC fonctionne sur des environnements Linux et Windows.
UnderC gère une version de «poche » des libraires C++ et permet d importer des librairies
externes. UnderC peut aussi s utiliser comme un interpréteur Shell, c'est-à-dire que les
instructions sont saisies en lignes de commandes et offre des commandes internes. Ces
commandes internes permettent entre autres de charger un fichier de code (#l fichier.c), et
de l exécuter (#r fichier.c). Il permet aussi d exécuter dans son interface des commandes
Shell (exemple : #x dir ou #x ls a). Certaines options permettent d avoir un verbose mode et
de tracer une fonction lors de son exécution.
Prenons le programme « testinterpC.c » listé ci-dessous qui effectue des opérations simples sur des
variables entières.
/*testinterpC.c
*/
#include
void main(int argc,char *argv[])
{
int x,y,z,w,v;
x=0;
y=1;
printf("valeur de x = %d\n",x);
printf("valeur de y = %d\n",y);
z=x+y;
printf("valeur de z(x+y) = %d\n",z);
x=3;
y=4;
w=x-y;
v=z*w;
printf("valeur de x = %d\n",x);
printf("valeur de y = %d\n",y);
printf("valeur de w(x-y) = %d\n",w);
printf("valeur de v(z*w) = %d\n",v);
}
On peut voir à la figure 10 un aperçu du chargement du code source et de son exécution avec les
commandes #l et #r.
L exécution du code testé a nécessité de modifier l écriture de la déclaration de la fonction main()
car UnderC ne prend en compte la fonction main() que ci cette dernière est écrite sous la
forme : void main(int argc, char *argv[]).
Bien que les fonctionnalités d UnderC soient intéressantes, son installation sous Linux ne fut pas
sans peine. En effet, UnderC a été développé sous RedHat 7.0 avec un noyau 1.2.9 et nécessite la
librairie libc 6 pour pouvoir s installer. Or les systèmes Linux actuels sont basés sur des noyaux
beaucoup plus récents (un noyau 2.4.20 pour la RedHat 9.0 -actuelle dernière version-), de plus
les nouvelles versions de GCC (actuellement la dernière version de GCC est 4.0.1) ne supportent
plus la librairie libc6. Donc utiliser UnderC nécessite une ancienne version de Linux et/ ou du
compilateur GCC.
25

Figure 10. Exemple d utilisation de l interprète UnderC
De plus, nous voulons dans le cadre de notre projet pouvoir interpréter des programmes C écrits
suivant la norme ISO99 et basés sur la norme ANSI C. Or UnderC ne supporte pas les librairies
standard C suivantes : « ctype.h », « errno.h », « float.h », « limits.h », « locale.h », « setjmp .h» et « signal.h »,
ce qui signifie qu UnderC ne prend en charge qu environ la moitié de la librairie standard C,
contrairement à ce qui est dit dans la documentation de l interprète.
Du fait de ces limites, surtout en ce qui concerne la prise en charge des librairies standard du C,
et en plus de sa lourdeur d utilisation (saisie non intuitive dans l interface, messages d erreurs peu
clairs et non documentés, bug dans le report des numéros de lignes du code source), l interprète
UnderC n est pas sélectionné pour le reste des tests.
3.2. Cint
Cint est un interpréteur C/C++ qui permet d interpréter à 95% de l ANSI/ISO C et à 80% du
C++ d après son auteur Masaharu Goto [GOT 05]. Cet outil a été créé en 1995 et est resté en
développement jusqu à aujourd hui où la dernière version 5.16.2 a été mise en ligne en juillet 2005.
La version sur la quelle se sont portés mes premiers tests est la version 5.15.171 qui comportait
plus de bugs que la nouvelle version. Les traces d exécutions et tests de cette section ont été
réalisés avec la dernière version de l outil.
Tout comme UnderC, Cint permet d exécuter un fichier de code C grâce à des commandes
internes. Ces commandes internes servent aussi à interpréter des instructions saisies en ligne de
commande, il s utilise ainsi comme un interpréteur Shell. Cint supporte l ensemble des librairies
standard du langage C et permet aussi d importer des librairies externes comme pour UnderC.
Cint contient un débuggeur intégré GDB Like pour les programmes à interpréter. De plus, Cint
fonctionne sur plusieurs types d OS dont Windows et Linux, il a même pu l installer sur la
dernière version de Mandrake (v. 10.1) sans difficulté, avec un compilateur GCC de version 3.4.1.
26

Chapitre 3
Les interprètes C existants
Sur la figure 11 ci-dessous, on peut voir les résultats d exécution du fichier de test « testinterpC.c »
donné dans la sous-section 3.2.
Figure 11. Exemple d utilisation de Cint sous Linux
Une trace d exécution de Cint avec l option de trace est donnée en annexe I.
Nous allons exécuter maintenant Cint avec le programme LLisp [GRE 97], qui est un petit
interprète du langage Lisp écrit en C entre les années 1990 et 1997 et comporte environs 1200
lignes de code source. On peut voir au préalable une démonstration de ce programme :
lysop@ko> ./llisp
Chargement de llisp.ini
append
length
assq
equal
member
? 5
= 5
? (car '(a b c))
= a
? (cdr '(a b c))
= (b c)
? bonjour
Atome bonjour, valeur indefinie
? (exit)
Bye ...
Exécutons maintenant ce programme via l interprète Cint, en y appelant les mêmes commandes
lisp que dans l exemple donné plus haut :
lysop@ko> cint llisp/eval.c llisp/mem.c llisp/read.c llisp/print.c llisp/std.c
llisp/main.c
Limitation: setjmp() not supported
Le fichier llisp.ini n'existe pas
? 5
= 5
? (car '(a b c))
Elt inconnu en position fonctionnelle 4
Limitation: longjmp() not supported
Liste non lambda en position fonctionnelle 4
27

Limitation: longjmp() not supported
Fonction standard inconnue car
Limitation: longjmp() not supported
car : Nb d'arguments incorrect
Limitation: longjmp() not supported
= (car (quote (a b c)))
? bonjour
Atome bonjour, valeur indefinie
Limitation: longjmp() not supported
= undefined
? (cdr '(a b c))
Elt inconnu en position fonctionnelle 5
Limitation: longjmp() not supported
Liste non lambda en position fonctionnelle 5
Limitation: longjmp() not supported
Fonction standard inconnue cdr
Limitation: longjmp() not supported
cdr : Nb d'arguments incorrect
Limitation: longjmp() not supported
= (cdr (quote (a b c)))
? (exit)
Elt inconnu en position fonctionnelle 25
Limitation: longjmp() not supported
Liste non lambda en position fonctionnelle 25
Limitation: longjmp() not supported
Fonction standard inconnue exit
Limitation: longjmp() not supported
exit : Nb d'arguments incorrect
Limitation: longjmp() not supported
= (exit)
?
!!! Middle of loop compilation run. signal(2)
!!! Break in the middle of compiled statement. signal(2)
FILE:print.c LINE:24 cint> exit
Bye... (try 'qqq' if still running)
Message d échappement de Cint
On remarque alors que Cint supporte l appel d un programme avec plusieurs fichiers sans avoir
eu à modifier la syntaxe du programme source. Mais nous remarquons également que le
programme ne supporte pas la fonction longjmp() appartenant au fichier d en-tête « setjmp.h »,
ce qui cause une mauvaise exécution du programme LLisp. On peut voit sur la trace d exécution
de LLisp ci-dessus que la commande exit, qui permet de quitter l interprète lisp, n est pas prise
en compte par Cint étant donné que les initialisations du programme LLisp ne sont pas
effectuées correctement, de sorte qu aucune fonction (car, cdr, exit, ..) n est reconnue.
Cet interprète présente quelques avantages surtout dans sa nouvelle version dont plusieurs bugs
ont été corrigés. Mais comme il a été dit en début de sa présentation, Cint ne traite que 95% du
langage ANSI/ ISO C et cela s est de plus vérifié dans le dernier exemple ; c est pourquoi je ne l ai
pas testé plus en avant.
3.3. JFL C
Ce programme [LUC 05] propose une interface graphique pour saisir les instructions en pseudo
langage C. Le concepteur du programme, Jean-François Lucas, a essentiellement orienté son
projet pour l apprentissage de la programmation aux jeunes élèves avec de simples fonctions
prédéfinies permettant de déplacer une tortue à l écran telles que : av(x) pour un déplacement
de x pixels vers l avant, dt(x) pour un déplacement de x pixels vers la droite, td/tg(y) pour
28

Chapitre 3
Les interprètes C existants
un déplacement de y degrés vers la droite/gauche. On peut également y charger des programmes
écrits en pseudo C. Cet interprète C comporte une interface graphique assez intéressante que
l ont peut voir à la figure 12 : un champ de saisie à gauche avec en dessous une fenêtre
d affichage des messages d erreurs et les commandes exécutées et également une fenêtre pour la
visualisation de l exécution des commandes à droite.
Figure 12. Aperçu de l interface JFL C
Figure 13. Exécution d un programme en pseudo langage C dans JFL C
29

Sur la figure 13, on peut voir l exécution d un programme en pseudo C qui vérifie l égalité entre
deux entiers : en cliquant sur le bouton d éclair à l extrême droite de la barre d outil, le résultat de
l exécution du programme est affichée à l écran de droite. On peut voir dans cet exemple que JFL
C utilise des fonctions qui lui sont propre pour gérer l affichage à l écran de droite (ve() pour
vider l ecran et ct() pour cacher la tortue) et des termes identiques au C tels que if pour le
contrôle et printf() pour l affichage mais comme on peut l observer leur syntaxe diffère de
celle du langage C.
JFL C propose un style de présentation intéressant pour le travail d analyse que l on veut faire
avec la représentation graphique. On pourrait en effet, à terme, adopter cette stratégie en
affichant à gauche le code source interprété et à droite le graphique de dépendances généré par
l interpréteur, avec une troisième fenêtre pour afficher le résultat d exécution.
Malheureusement, cet outil n interprète que 140 instructions propres à l outil et non au langage C.,
et ne gère pas les pointeurs dans sa version actuelle. De plus le code source de l outil n est pas
disponible, et la version testée est en période d essai. Ce programme est donc assez limité quant à
ce qu on recherche comme interprète de langage C.
3.4. EiC
EiC, Extensive Interactive C, a été conçu par Edmon J. Breen en 1995 [BRE 00] et a connu des
améliorations jusqu en 2000. Cet outil est dédié entièrement à l interprétation du langage C. Il
permet ainsi de saisir des instructions C en ligne de commandes comme les deux premiers
programmes précédemment décrits (UnderC et Cint). Il gère l ensemble des librairies standard du
langage C ainsi que les librairies OpenGL, SQL et permet avec des commandes internes de
générer des graphes avec gplot. L intégration de ces librairies à EiC nécessite cependant la
recompilation de celui-ci. Notre objectif actuel ne nécessite pas l utilisation de ces librairies et
fonctionnalités, mais leur intégration à l outil nous ouvre des possibilités à l avenir pour l analyse
de programmes C faisant appel à d autres librairies que les librairies standard C.
En plus de ces possibilités, l interprète EiC a la possibilité de s exécuter sur un grand nombre de
plateformes telles que Linux (elf), SUN SPARC SOLARIS 2.x, SUN SOLARIS/ i386 SUN OS
4.1.x, DEC ALPHA OSF 3.x et 4.x, SGI IRIX 6.x, FreeBSD, W32 et d autres encore. La liste
complète peut être consultable sur le site consacré à l outil [BRE 00].
La documentation fournie avec le programme EiC est bien faite, non complète mais suffisante
pour son utilisation (187 pages en format .pdf). Le code source est disponible aussi bien pour
Windows que pour Linux, ce qui nous intéresse plus étant donné que c est l environnement pour
lequel il existe des outils de développement dans le domaine public. Il existe également une
documentation technique mais non achevée.
La figure 14 donne un aperçu de l utilisation de l outil sous linux, spécialement comment l utiliser
pour interpréter le programme « testinterpC.c » en mode interactif et en mode batch. En mode
interactif les instructions sont interprétée une à une (cf. figure 14 déclaration de la variable x et
son affectation avec la valeur 10) et le fichier « testinterpC.c » doit être chargé dans l interprète avec
la directive #include, puis il est exécuté en faisant appel à la fonction main() qui y est définie.
En mode batch, le fichier source est donné en argument à la commande eic et l exécution du
programme est immédiate.
30

Chapitre 3
Les interprètes C existants
lysop@yak> ./eic
*************************************************************************
EiC V4.3.0 - Copyright (c) 1995 to 2000, by Edmond J. Breen
EiC comes `as is' and with ABSOLUTELY NO WARRANTY OF MERCHANTIBILITY AND
FITNESS OF PURPOSE
*************************************************************************
(void)
EiC 1> int x;
(void)
EiC 2> x = 10;
10
EiC 3> #include testinterpC.c
(void)
Mode interactif
EiC 4> main();
valeur de x = 0
valeur de y = 1
valeur de z(x+y) = 1
valeur de x = 3
valeur de y = 4
valeur de w(x-y) = -1
valeur de v(z*w) = -1
0
EiC 5> :exit
lysop@yak> ./eic testinterpC.c
valeur de x = 0
valeur de y = 1
valeur de z(x+y) = 1
valeur de x = 3
Mode batch
valeur de y = 4
valeur de w(x-y) = -1
valeur de v(z*w) = -1
lysop@yak>
Figure 14. Aperçu de l utilisation de EiC sous Linux
Bien que cet outil semble complet en ce qui concerne sa prise en charge de l ensemble du langage
C, un dernier test va me permettre de vérifier ses possibilités à gérer tout type de programme C.
Pour cela, je teste l interprète pour le programme LLisp, vu dans la section 3.2.
lysop@yak> ./eic llisp/main.c
Warning: in llisp/read.c near line 158: Unreachable code at line 157
Warning: in stdlib.h near line 31: 2nd prototype for builtin -> malloc
Warning: in stdlib.h near line 39: 2nd prototype for builtin -> free
Chargement de llisp/llisp.ini
append
length
assq
equal
member
? 5
= 5
? (car '(a b c))
= a
? (cdr '(a b c))
= (b c)
? bonjour
Atome bonjour, valeur indefinie
? (times 5 6)
= 30
? (add1 8)
= 9
? (plus 8 9)
31

= 17
? (exit)
Bye ...
lysop@yak>
Comme on peut le voir sur cette trace d exécution, les programme LLisp s exécute normalement
et sans générer de messages d erreurs pendant son exécution. Cependant l exécution du
programme source de LLisp a nécessité de mettre l ensemble du code source au format standard
moderne de C. En effet, étant donné que ce programme de test est assez ancien, il est
entièrement écrit avec l ancienne syntaxe du langage C (exemple : nom_fonction(x, y) int
x, float y ; {..}). Il a donc fallu mettre les définitions de fonctions au standard (void
nom_fonction(int x, float y) {..}) et la fonction main() au format : int
main(){..return 0 ;}. Il a fallu également redéfinir le prototype de certaines fonctions
standard, telles que malloc() et free(). En effet, la fonction free() doit retourner un type
void, alors que le programme LLisp déclarait cette fonction comme retournant un type char, ce
qui explique les messages d alertes affichés lors de l appel au programme LLisp via EiC, mais ces
alertes n empêchent pas EiC d exécuter le programme d interprète LLisp correctement. Il a
également fallu inclure en début du fichier « main.c » chaque fichier auquel il fait appel sous la
forme : #include fichier.c .
Bien que l interprète EiC nécessite une mise en forme des anciens programmes C aux dernières
normes ANSI et ISO C, il rassemble des caractéristiques assez proches de l interprète recherché
puisqu il gère l ensemble des spécificités du langage C : toutes les fonctions des librairies standard,
les pointeurs, les structures de contrôles, les fonctions récursives notamment.
3.5. Ch
L outil Ch est développé par SoftIntegration Corporation [SOF 05] depuis 2001 à nos jours. En effet
cet outil est toujours en perpétuelles améliorations. Ch était à la base dédié à interpréter le langage
C et destiné aux programmeurs désirant apprendre le langage C. Il a évolué pour servir
essentiellement au développeurs systèmes. Il permet dans sa version actuelle de prendre en
charge aussi bien le langage C que le langage C++. Il a également son propre langage Ch, qui se
positionne dans sa syntaxe entre le langage C et le C++. Ce langage possède une syntaxe prenant
en compte celle des deux langages C et C++, ce qui permet au développeur d écrire son code en
mélangeant les syntaxes et les fonctions des deux langages avec les fonctions propres au langage
Ch. En effet, le langage Ch possède des fonctions supplémentaires qui permettent entre autres de
connaître le type d une chaîne de caractère (elementtype(var)) ou encore de connaître si une
chaîne de caractère est un mot clé du langage (iskey(int)). On peut voir ci-dessous un
exemple de script Ch et le résultat de son exécution :
Fichier : « compare.ch »
#!/bin/ch -S
#include
int main() {
char s[]="abcd";
string_t p="abcd";
printf("strcmp(s, p) = %d\n",strcmp(s, p));
}
Figure 15. Exemple d'utilisation d'un script Ch
32

Chapitre 3
Les interprètes C existants
Comme on peut le voir sur la figure 15, la fonction strcmp() n est pas celle de la librairie
standard C puisque le fichier header «string.h » dans lequel elle est définie n a pas été inclus au
programme «compare.ch ». De plus cette fonction compare deux chaînes de caractères de types
différents l une de type char * comme en C et l autre chaîne est de type string_t qui est un
type propre au langage Ch. On peut aussi remarquer que le code Ch est enregistré dans un fichier
d extension .ch, qui contient en première ligne l appel à l interprète Ch sous la forme :
# !/bin/ch S .
L interprète Ch offre de plus la possibilité d utiliser des commandes Shell, awk et des librairies
graphiques telles que OpenGL. Il permet, comme UnderC, Cint et EiC, de saisir des instructions
C en ligne de commandes et d exécuter un fichier écrit en C de manière aisée. On peut voir cela à
la figure 16.
Figure 16. Aperçu de l exécution du programme testinterpC.c par Ch
Ch est accompagné de trois documents (de type pdf de plus de 1000 pages en tout) et man, assez
complets, permettant de mieux comprendre son langage et son fonctionnement.
Ch existe en version standard gratuite, dédiée à la recherche et aux étudiants, et une version
professionnelle payante. Nous avons testé la version standard de Ch dans l espoir de pouvoir
obtenir le code source par la suite, malheureusement sans succès. Les tests réalisés sont les
mêmes que ceux appliqués à l outil EiC étant donnés que l outil gère toute la bibliothèque
standard C, ainsi que les principaux éléments pouvant construire un quelconque programme
source C, c'est-à-dire essentiellement : les pointeurs, les tableaux, l appel de fonctions, gestion des
boucles, la récursivité et encore les structures de contrôle.
Ch permet aussi de gérer un code source avec grand nombre de lignes de codes. Il a été
cependant incapable d exécuter le code de l interprète Lisp constitué de plusieurs fichiers sources,
ceci bien qu il supporte en théorie la possibilité d interpréter ce type de programmes sources. En
effet, l exécution de programmes composés de plusieurs fichiers sources nécessite des
manipulations préalables sur ce dernier. Le code source n étant de toute manière pas accessible,
les tests pour cet outil n ont pas été au delà.
Le langage Ch permettrait aussi de créer des programmes avec des points de contrôle grâce aux
fonctions Ch, mais cela nécessite une étude plus approfondie de ses capacités, difficile à réaliser
du fait du manque de documentation à ce sujet.
33

3.6. Pourquoi EiC ?
Après avoir exposé les spécificités de chaque interprète, le nombre d interprètes réellement
utilisable pour le projet, s avère assez limité comparé à ce qu on espérait au départ, à savoir un
interprète capable de prendre en charge le langage C avec toutes ses possibilités, et dont le code
source soit dans le domaine public. En effet, tous les interprètes disponibles soit ne prennent pas
en charge à 100% la bibliothèque standard C (cf. UnderC, Cint et JFL C), soit prennent en charge
l ensemble de la librairie mais nécessitent de modifier le code source à analyser (cf. EiC pour la
fonction main() par exemple). De plus la gestion des programmes sources faisant appel à
plusieurs fichiers n est pas assez bien gérée par les deux derniers interprètes EiC et Ch, bien qu ils
gèrent de manière assez complète les spécificités du langage C. Cint parvient à exécuter ce type de
programmes d une manière assez proche de celle de gcc mais ne supporte pas la librairie standard
« setjmp.h » de même que d autres librairies standard, du moins l ensemble des fonctions qui y sont
définies.
Bien que Ch soit un très bon outil d interprétation du langage C, il n a pas son code source
accessible, ce qui rend impossible la possibilité de lui intégrer la fonctionnalité d analyse de
programmes. Cint malgré sa facilité d utilisation, ne supporte qu à 95% les spécificités du langage
C (ANSI ET ISO C).
C est pour ces raisons que mon choix s est orienté vers EiC qui a l avantage de prendre en charge
l ensemble de la libraire standard C 6 et d avoir son code source accessible. Il nécessitera de
manipuler le code source au préalable (surtout pour les anciens codes sources). Malgré le fait que
EiC n ait plus été amélioré depuis 2000, il reste un interprète assez bien conçu et le plus complet
de part son débuggeur intégré et d autres fonctionnalités comme la trace d un programme qui
font défaut à l heure actuelle dans Ch et qui n est pas assez performante dans Cint.
Dans le chapitre 4 qui suit, je détaille les spécificités de l interprète EiC, les possibilités qu il offre
ainsi que les limites qu'il impose.
6
A l exception de la librairie
34

Chapitre 3
Les interprètes C existants
35

Analyse dynamique de programmes C
Chapitre 4 - Exploration de l interprète
EiC
Après avoir vu dans le chapitre précédent les aspects généraux de EiC, ses contraintes, ses
avantages ainsi que les raisons pour lesquelles il s est imposé comme unique solution pour notre
projet, ce chapitre décrit l interprète EiC de manière plus précise d un point de vue technique.
Dans les paragraphes qui suivent, j expose en un premier temps les spécificités de l interprète
EiC puis je décris l organisation de ses fichiers sources. En effet, une prise de connaissance du
fonctionnement et de l organisation du programme EiC permet de mieux aborder la modification
de son code source.
4.1. Spécificités de EiC
Cette section détaille l utilisation de EiC, présente ses limitations de syntaxe pour les codes
sources C ainsi que ses possibilités encourageantes pour la réalisation de notre objectif.
4.1.1. Installation et compilation
La version utilisée de EiC est la version source pour le système Unix. Elle peut être librement
téléchargée sur le site officiel [BRE 00]. Le code source a été installé sur une machine SunOS (5.9
Generic, sun4u, sparc) du Laboratoire d Intelligence Artificielle de l Université Paris 8 7 .
L installation du programme n est pas entièrement automatique ; elle nécessite la modification
d un fichier de configuration de EiC puis de l exécution de quelques commandes dont un make
install pour l installation propre du programme sur la machine SunOS.
Après installation du code source de l interprète EiC, une variable d environnement propre à EiC
HOMEofEiC doit être initialisée avec le chemin du répertoire de EiC, dans le fichier « .bashrc » ou
directement dans un terminal Korn Shell. Cette variable permet à EiC de connaître le chemin
vers les fichiers constituants la librairie standard du C.
4.1.2. Les modes d exécution de l Interprète EiC
4.1.2.1. Le mode interactif
EiC, comme son nom l indique est un interprète interactif. Ce mode est lancé directement à partir
du prompt Shell par la commande suivante : $eic.
Un prompt EiC s affiche alors invitant l utilisateur à saisir les instructions C :
7
Notons que c est uniquement sur cette plateforme que nous avons pu à ce jour compiler les sources de EiC.
36

Chapitre 4
Exploration de l interprète EiC
lysop@yak> ./eic
*************************************************************************
EiC V4.3.0 - Copyright (c) 1995 to 2000, by Edmond J. Breen
EiC comes `as is' and with ABSOLUTELY NO WARRANTY OF MERCHANTIBILITY AND
FITNESS OF PURPOSE
*************************************************************************
(void)
EiC 1> #include stdio.h
(void)
EiC 2> printf("Hello world");
Hello world 11
EiC 3>
Comme on peut le voir sur cet exemple, on peut saisir des instructions C tout comme on pourrait
les saisir dans un fichier texte ou encore un éditeur de code C. Observons de plus près la
première instruction saisie dans cet exemple : on peut voir que le fichier « stdio.h » inclus n est pas
entouré par les caractères < > comme on le fait normalement en C. Ceci montre qu il subsiste
des différences entre le C et le C de EiC entré interactivement. Ces différences vont être abordées
dans la section 4.1.3. Quand EiC est exécuté en mode interactif, il charge en mémoire certains
fichiers headers de la librairie standard du C, la liste de ces fichiers peut être visualisé et même
paramétrée dans le fichier « starteic.h », qui est appelé lors de l appel au programme EiC. Le
lancement de EiC en mode interactif crée un fichier d historisation «EiChist.lst » qui permet de
stocker les commandes exécutées depuis le début du programme EiC, ce fichier est utilisé pour
faciliter la saisie des commandes dans ce mode.
Il existe également des commandes internes au mode interactif de EiC, qui permettent entre autre
de charger en mémoire un fichier de code C, de visualiser le code intermédiaire que traite le
préprocesseur ou encore de donner le temps d exécution d un programme dans l interprète. Ces
commandes sont appelées par le caractère «: » suivi du nom de la commande, puis suivant la
commande un ou plusieurs arguments. Par exemple la commande :exit permet de quitter le
mode interactif de EiC, ou encore :
EiC 3> void fonction (int x){ int y; y = x+6; printf("y = %d\ n",y); }
(void)
EiC 4> :show fonction (4);
fonction -> Func (
x: int
) returning void
4
La commande :show, comme on peut le voir ci-dessus, permet de montrer la structure de la
fonction définie en ligne 3 avec le type des paramètres passés en arguments, ici l argument x est
de type int, et la fonction retourne un type void. La valeur 4 retournée en dernier correspond
à la valeur de l argument x.
L ensemble des ces fonctions sont listées avec leur description en annexe II.
Exemple d exécution de
la commande de trace
EiC 8> :trace
EiC 9> fonction (4);
9,
[fonction] 3,y = 10
[::EiC::] 9,
(void)
EiC 10> :listcode
0:halt
(void)
EiC 11> fonction (4);
0:pushptr b2868
1:bump 1
2:checkar 1 1
3:pushint 4
4:stoval
5:pushint 1
6:eiccall
Visualisation du code
intermédiaire généré par
EiC pour la fonction :
fonction(4)
37

Chapitre 4
Exploration de l interprète EiC
7:halt
y = 10
Pour l exemple donné pour la commande de trace, le nombre 9 correspond à la ligne EiC à partir
de laquelle est exécutée l instruction tracée, puis le nom de la fonction est affiché entouré de [ ]
avec le numéro de ligne EiC où elle a été définie. Comme la fonction est définie sur une seule
ligne, seul ce numéro apparaît, suivi du résultat de l appel à printf() avec la valeur de y qui
comme on peut le remarquer égale à la somme de 4 (valeur de x) et de 6. Après exécution de
cette fonction d après la trace obtenue, EiC revient à la ligne 9 où fonction(4) à été appelée.
Le mode interactif permet également d exécuter une instruction qui tient sur plusieurs lignes. Ceci
s effectue de deux manières, la première étant de placer un antislash («\ ») à la fin de chaque
instruction sauf à la dernière comme on peut le voir sur l exemple suivant :
EiC 1> double sqr(double x)\
EiC 2> {\
EiC 3> return x*x;\
EiC 4> }
(void)
EiC 5> sqr(2);
4
La deuxième manière est d utiliser le préprocesseur de EiC pour inclure la suite d instructions.
Pour cela, les instructions sont saisies dans un fichier qui sera alors inclus grâce à la directive
#include du préprocesseur. Pour reprendre l exemple présenté précédemment, on crée le
fichier « sqr.c » (ci-dessous à droite), puis on le charge dans EiC comme suit :
EiC 6> #include sqr.c
(void)
EiC 7> sqr(2);
4
/* Fichier sqr.c
*/
#include
double sqr (double x)
{
return x*x;
}
Après avoir aperçu les particularités du mode interactif de l interprète EiC, je vais détailler les
autres possibilités offertes par le mode non interactif de EiC.
4.1.2.2. Le mode batch
Comme il a été dit précédemment, EiC peut s exécuter en mode batch, c est-à-dire à la manière
d une commande Shell dans un environnement Linux, ce mode n étant d ailleurs possible qu en
environnements Unix ou Linux. Cette option d EiC permet aussi d interpréter des fichiers de
code source C sans avoir à les charger au préalable, comme c est le cas en mode interactif. Pour
exécuter le code C contenu dans le fichier « var.c » listé ci-dessous, il suffit de saisir au niveau du
prompt Shell la commande suivante : $> eic var.c.
1 /*
2 var.c
3 fichier simple qui affecte une variable
4 */
5 #include
6 int main()
7 {
8 int x;
9 x = 12;
10 printf("x = %d\n", x);
11 return 0;
12 }
Résultat d exécution :
lysop@yak> ./eic var.c
x = 12
38

Chapitre 4
Exploration de l interprète EiC
Le fichier est alors exécuté sans pour autant générer un fichier binaire, comme le ferait un
compilateur. Notons que le programme « var.c » n est exécuté par l appel à EiC en mode batch
que s il contient la définition d une fonction main(). En effet, la fonction main est considérée
par EiC comme le point de départ du programme. Cette remarque s applique aussi au mode
interactif de EiC, qui ne permet pas d exécuter un fichier source C sans que ce dernier possède la
définition d une fonction main(). Les prototypes possibles pour définir la fonction main()
sont décrits dans la sous-section 4.1.3.
Avec l appel de EiC en mode batch, le fichier de code source qu on lui donne en argument est
considéré avec tous les fichiers headers qu il inclut comme une seule unité à traduire et à
interpréter. De plus, il n y a aucun fichier d historisation (« EiChist.lst ») créé, contrairement à
l utilisation du mode interactif.
Il existe des particularités d exécution qui sont communs aux modes batch et interactif : le mode
batch possède la possibilité de spécifier des options d exécution, certaines ont même les mêmes
fonctionnalités que celles du mode interactif. Seul le mode d activation de ces options change
d un mode à l autre. On a vu dans la section précédente que les options sont toujours précédées
par le caractère «: ». Pour le mode batch, les options sont toujours précédées du caractère «- », à
la suite de ce caractère on peut cumuler les options les unes après les autres, tout comme les
commandes Shell en environnement Unix/ Linux. La liste complète de ces options est donnée en
annexe II. Quelques options sont cependant présentées ci-dessous avec la trace de leur exécution.
Mais avant cela, voici le format général de la commande eic peut être utilisée en mode batch :
eic [-Directives pour le préprocesseur C] [-Options pour EiC] [ [fichier] [arguments] ]
Ci-dessous quelques exemples d utilisation des options p, t et c qui permettent respectivement
d afficher le code interprété avant de l exécuter, de tracer les instructions effectivement exécutées
et enfin de mesurer le temps d exécution des instructions :
1. ./eic -ptc var.c
2. int _Argc = 1;char *_Argv[] = {"var.c",(void*)0};
3. : 0
4. int main()
5. {
6. int x;
7. x = 12;
8. return x;
9. }
10. : 0
11. main();
12. 5,
13. [main] 9,10,
14. [::EiC::]
15. : 0
Dans cet exemple, on exécute le fichier « var.c » (cf. ci-dessous). La ligne 1 correspond à l appel de
la commande eic avec les trois options ptc, décrites plus haut. La ligne suivante montre la
première ligne interprétée par EiC (comme on a activé l option p pour l affichage des instructions
interprétées), qui correspond à l affectation des variables internes à EiC :_Argc et _Argv. Leurs
valeurs nous indiquent que le programme EiC prend le fichier « var.c » en argument et c est donc
cet unique fichier qui sera à traiter, ce qu on peut effectivement voir aux lignes 4 à 9 (option p).
39

Chapitre 4
Exploration de l interprète EiC
L interprète lit les lignes du fichier « var.c » ligne par ligne à partir de la définition de la fonction
main(), puis exécute celle-ci comme une seule instruction. Les lignes 12 à 14 correspondent à
l exécution de la trace du programme var.c. On peut remarquer que l option de trace en mode
batch de EiC donne le même type d affichage qu en mode interactif (cf. page 32). La mesure du
temps d exécution de chaque instruction est affichée aux lignes 3, 10 et 15, le temps étant mesuré
en secondes (option c).
L interprète EiC présente donc des particularités et des possibilités assez intéressantes pour notre
projet, essentiellement l option de trace et d affichage d instructions interprétées pendant leur
exécution. EiC nous permet non seulement d exécuter un fichier de code C en mode batch, mais
offre aussi la possibilité d être intégré dans un fichier de script. Ce fichier de script devra
commencer par la ligne #!/chemin/vers/eic pour un fichier contenant un programme C et
par #!/chemin/vers/eic f pour un fichier de script EiC 8 [BRE 03]. Les fichiers de
scripts EiC auront pour extension .eic, peuvent contenir des fonctions EiC et peuvent être
exécutés simplement au prompt Shell par l appel suivant : $./fichier.eic. Nous ne
détaillerons pas plus ce mode d exécution car il présente globalement les mêmes spécificités que
le mode batch.
4.1.3. Les différences entre EiC et C
Du fait de son interactivité EiC diffère du C de plusieurs manières. Ces différences mettent en
avant surtout les quelques lacunes de EiC à interpréter tout programme écrit en langage C suivant
la norme ISO, mais cela ne met pas en doute les qualités de EiC en tant qu interprète C complet
et fiable pour interpréter et exécuter la plupart des programmes C (cf. section 3.4).
EiC détecte plusieurs classes mémoire en violation de lecture ou d écriture [BRE 03].
Les structures et unions ne peuvent pas être passées en argument dans une fonction à
arguments variables. Ex :
EiC 2> struct stag {int x; double y[5];} ss;
(void)
EiC 3> void foo(const char *fmt, ...);
(void)
EiC 4> foo("",ss);
Error in ::EiC:: near line 4: passing a struct/union to variadic function `foo'
Le concept d édition de liens en C n est pas supporté par EiC, ceci du fait que EiC
fonctionne suivant le concept d une seule unité de traduction : tous les fichiers appelés par
un programme doivent y être incluses au fichier « main.c ».
EiC ne supporte pas les séquences trigraphes 9 , ni les caractères étendus (de type
wchar_t définit dans < stddef.h> pour définir des caractères asiatiques par exemple), ni
les chaînes de caractères étendues.
Le fichier header standard n est pas géré.
8 EiC possède des fonctions internes non existantes dans les librairies standard du C, qui permettent notamment
de connaître le type des variables manipulées par exemple.
9
EiC dispose d un jeu de caractères restreint, correspondant à la norme ISO646. La norme ANSI permet que
certains des 9 derniers caractères (# [ \ ] ^ { | } ~) soient remplacés par des séquences trigraphes. Une séquence
trigraphe est une suite de 3 caractères commençant par ?? [DEL 03].
40

Chapitre 4
Exploration de l interprète EiC
Toute fonction dans EiC doit être explicitement définie avec son type de retour, quelque
soit le type :
EiC 3> foo(){ int x; x=2; return x; };
Error in ::EiC:: near line 3: Undeclared identifier foo
Error in ::EiC:: near line 3: Expected ;
Error in ::EiC:: near line 3: Misplaced return statement
Error in ::EiC:: near line 3: Expected ;
EiC 5> int foo(){ int x; x=2; return x; };
(void)
L ancienne syntaxe de déclarations et de définitions de fonctions C n est pas supportée
par EiC, telle que :
int f(value) int value { } /* illégal -> vieux style de syntaxe C */
Le préprocesseur de EiC ne gère pas la directive #line.
EiC a donné à la directive #include plus de possibilités comme l inclusion d un fichier
source sans " " ou < >.
Les différences entre EiC et l ISO C sont essentiellement dues au fait que EiC est un interprète
du langage C. Ainsi, EiC est capable de supporter l ensemble des spécificités du langage C, mis à
part deux ou trois fonctionnalités et syntaxes non encore supportées [BRE 03]. Ces lacunes ne
sont cependant pas un handicap, elles vont seulement nous contraindre à mettre en forme le code
C avant de l interpréter avec EiC.
4.2. Structure de fichiers
Nous présentons dans cette section l arborescence des principaux fichiers sources constituant
EiC, de manière à montrer le rôle que jouent certains fichiers dans la procédure d interprétation
et d exécution du code C. Dans la figure 17 ci-dessous, on peut voir l arborescence des dossiers
avec le détail du contenu des principaux répertoires. Seuls les principaux dossiers et fichiers
impliqués dans le processus d interprétation de code sont décrit dans ce qui suit.
Le dossier bin/ contient le fichier binaire « eic » (surligné en jaune sur la figure 17) généré quand
on compile le code source de EiC ($make install dans le dossier eic_test/ ).
Les sources de l interprète sont situées sous le dossier racine eic_test/ , nous avons
volontairement omis de mettre le contenu de quelques répertoires ( config/ , doc/ , lib/ ,
module/ et test/ ) qui ne jouent pas de rôle dans la procédure d interprétation de code.
Les principaux dossiers détaillés dans cette section sont les dossiers include/ , main/ et src/ .
Le dossier config/ contient les informations de configuration relatives à chaque environnement
sur lequel fonctionne EiC. Le dossier doc/ , comme son nom l indique, contient un ensemble de
documentations techniques sur EiC. Les dossiers lib/ , module/ et tests/ contiennent
respectivement des fichiers binaires spécifiques à EiC, des modules tels que gnuplot et le
traitement des cgi par EiC et des exemples de programmes test pour l interprète.
41

Chapitre 4
Exploration de l interprète EiC
Figure 17. Arborescence des fichiers sources de EiC
Comme il a été dit dans le chapitre 3, EiC est capable de traiter la librairie standard C dans sa
totalité, mis à part le fichier < locale.h>. Dans le dossier include/ , on trouve tous les fichiers
headers traités par EiC. On remarque alors qu il existe en plus des headers standard (surlignés en
vert), des headers correspondants à la librairie POSIX.1 tels que , < fcntl.h>,
(surlignés en bleu). Les fichiers restants (non surlignés) correspondent aux fichiers d entête
spécifiques à EiC et qu on retrouve également dans le dossier src/ . Ce dossier src/ contient les
fichiers sources de l interprète, et représente ainsi le noyau de EiC. Remarquons que le fichier
« starteic.c » contient les principales fonctions lançant le mécanisme d interprétation, il effectue les
traitements du préprocesseur «à la volée » et vérifie la syntaxe des instructions avant de les
représenter dans un format interne (byte code) détaillé dans le chapitre 5.
L analyse va aussi créer une table de symboles (symbol table) qui contiendra des informations sur
les chaînes de caractères (variables, nom de fonctions, nom de structures, par exemple)
concernant leur position dans l instruction, leur type, ou encore leur niveau d appel dans le code.
La définition des structures de table de symboles se trouve dans les fichiers « datastruct.h » et
« eicval.h ». Les fonctions manipulant les éléments de la table des symboles se trouvent dans le
fichier « symbol.c ».
42

Chapitre 4
Exploration de l interprète EiC
Le fichier « preproc.c » contient les fonctions nécessaires pour le prétraitement du code. EiC utilise
une grammaire LL(1) 10 , avec un mécanisme d analyse descendante [GRU 00], qui a une assez
bonne capacité de récupération d erreur. Le travail de l interprète est définit dans le fichier
« interpre.c », qui contient une unique fonction appelée EiC_interpret(environ_t * env). Nous
verrons dans le chapitre suivant l importance du rôle joué par ce fichier pour la réalisation de
notre travail d analyse dynamique de code, notamment pour modifier l option de trace de EiC.
Lors de l exécutionde EiC, le premier fichier appelé est « main.c » 11 , qui comme son nom l indique
contient la fonction main() du programme et permet essentiellement à charger les librairies «
libstdClib.a » qui contient la librairie standard C et « libeic.a » qui contient les fonctions propres à
EiC, crée un lien entre elles, puis fait appel aux fonctions de « starteic.c ». Ce dernier fichier lance
l anlyse des instructions C ainsi que leur interprétation. C est dans le fichier «interpre.c » que se
trouve la bourcle d exéctution des instructions (en byte code) et c est également dans ce fichier que
l option de trace est définie, c est donc ce fichier que nous avons modifié essentiellement pour
réaliser notre travail d analyse dynamique.
L étude des différents aspects de EiC et l organisation de sa structure de fichier nous ont permit
de prendre en considération toutes les possibilités de EiC qui peuvent nous servir dans la
réalisation de notre travail d analyse dynamique, les possibilités qu offre le mode batch de EiC
tout particulièrement et l option de trace de l interprète. Cette présentation nous a également
permis de connaître les points à améliorer dans EiC dans les travaux futurs, comme la prise en
compte de fonctions sans types de retour, la prise en compte de la librairie standard .
10
La description de cette grammaire peut être trouvée dans la documentation technique de EiC se trouvant dans
son source (cf. eic_test\doc\tech_doc\LL1).
11
Le fichier « main.c » se trouve dans le dossier nommé /main (cf. figure 17)
43

Chapitre 5 - Description technique du travail réalisé
Chapitre 5 - Description technique du
travail réalisé
Avant d aborder ce chapitre rappelons par un petit exemple ce que l on entend par
dépendances dynamiques de données, prenons pour cela le fichier de code C nommé « exemple.c ».
Le travail décrit dans ce chapitre permet de générer un graphe de dépendance entre les données
tel qu on peut le voir ci-dessous.
1 /*
2 exemple.c
3 */
4 int main()
5 {
6 int x,y,a;
7 x = 12;
8 y = 8;
9 a = x + y;
10 return 0;
11 }
7
x=12
9
a=20
8
y=8
Ce chapitre présente les techniques utilisées pour l extraction des informations de codes sources
C pendant leur exécution dans EiC. Nous y expliquons dans un premier temps de quelle manière
l extraction des données est réalisée à l aide de l interprète EiC, ce qu il a fallu y modifier et le
format des données extraites. Puis dans un second temps, nous expliquons comment est exploité
le fichier de base de données extrait pour générer la représentation graphique des dépendances
entre les données et comment interpréter le graphique généré.
5.1. Extraction dynamique des données
L interprète EiC, comme nous avons pu le voir dans le chapitre précédent, possède deux modes
d exécutions. Nous avons également vu que le mode batch nous permet d intégrer l appel à EiC
dans un fichier de scripts Shell. C est pour ces raisons que nous avons choisi de travailler sous le
mode batch, d autant plus qu il offre la possibilité de tracer un programme. Cette dernière
possibilité de l interprète nous a semblé intéressante à exploiter et à étendre sa fonctionnalité afin
qu elle génère des informations sur les données manipulées par le programme C. Mais avant
d aborder l aspect technique du travail réalisé, nous précisons que tout notre travail s est
concentré à traiter les cas de manipulation de données de types entières. Le traitement des autres
types sera effectué par la suite de la même manière en y appliquant de simples réajustements
suivant le type traité (cf. chapitre 8).
La section 5.1.2 détaille comment l option de trace est modifiée dans EiC, et les deux soussections
suivantes, 5.1.3 et 5.1.4, expliquent le format d extraction des données. Mais avant de
voir cela, commençons par voir les étapes suivies pour extraire des informations à partir d un
fichier de code source simple.
44

Analyse dynamique de programmes C
5.1.1. Description de la procédure d extraction
La figure 18 présente le schéma général de la procédure d extraction pour un programme C, ici
« test.c » comme exemple. Pour analyser ce dernier, on l interprète d abord par EiC avec l option
de trace modifiée : $./eic t chemin/vers/test.c.
L exécution de cette commande génère l affichage des données extraites en sortie standard. Afin
de pouvoir exploiter ces informations, le résultat de la commande est donc redirigé vers un
fichier qui se nomme « test.data », ce dernier forme alors la base de donnée.
Cette base de données est utilisée ensuite par un script awk qui va mettre les données sous un
format pouvant être exploité par l outil d affichage de graphes Dot [GAN 02]. Les données ainsi
mises en forme seront enregistrées dans un nouveau fichier d extension .dot. Ce fichier contient
donc l ensemble des informations extraites du code source avec les liens les reliant les unes aux
autres pendant l exécution du programme source.
Le fichier « test.dot » est ensuite transformé par le programme Dot en fichier d extension .ps
(« test.ps »), ce qui nous permet de le visualiser avec l application GhostView ou encore le
transformer en format PDF, plus facilement exploitable.
Code
Source C
« test.c »
Interprétation
par EiC
modifié
$eic t test.c
Base de
données
« test.data »
Exploitation
par un script
awk
« graph.awk »
Fichier mis en
forme pour
Dot
« test.dot »
GhostView
Fichier
PostScript
« test.ps »
Dot
Figure 18. Schéma d'extraction dynamique de données
L ensemble de ces étapes pour la génération du graphique de dépendances des données, est
effectué par un script Shell nommé « eic_adpc.sh » (Analyse Dynamique de Programmes C basée
sur EiC). L appel à ce script nécessite de passer en argument le nom du fichier de code source à
analyser. Si un fichier de code est passé en argument, il est alors analysé afin de vérifier son
extension (.c) et dans le cas où celle-ci est correcte, une dernière vérification est effectuée pour
voir si le fichier existe bien et s il est en droit de lecture. Si une de ces conditions n est pas vérifiée,
un message d erreur est affiché pour en avertir l utilisateur. Ce script est donné en annexe V.
45

Chapitre 5 - Description technique du travail réalisé
Pour que le script Shell fonctionne correctement, le fichier de code source doit être placé dans un
dossier qu on a crée spécialement pour les codes sources à analyser. On verra dans le paragraphe
qui suit les autres dossiers ajoutés à EiC, ainsi que les fichiers modifiés.
5.1.2. Modifications apportées à EiC
Comme nous avons vu au chapitre précédent, le programme binaire qui permet d exécuter EiC se
trouve dans le dossier dossier_install_eic/bin et a pour nom eic. C est également dans ce
dossier que se trouvent les scripts Shell et awk, ainsi que les dossiers que manipule « eic_adpc.sh »,
listés ci-dessous :
- codes_test/ : contient les programmes C utilisés pour les tests et ceux à analyser.
- data/ : contient les fichiers de base de données générés par EiC.
- dot/ : contient les fichiers d extension .dot généré par le script awk.
- graphs/ : contient les fichiers PostScript pour la visualisation du graphe de dépendance.
Grâce au script Shell, chaque fichier généré au cours de son exécution est placé dans le dossier
correspondant.
Mis à part ces ajouts dans le dossier bin/ de EiC, d autres modifications ont été effectuées à
certains fichiers du dossier eic_test/src/ , qui contient les fichiers sources de l interprète.
Comme nous l avons précisé précédemment, l option la plus proche de ce que l on veut faire est
l option de trace d un programme, qui permet de retourner le numéro de ligne des instructions
exécutées avec éventuellement leur résultat d exécution. L exemple qui suit, montre le résultat
retourné par cette option de trace avant sa modification :
lysop@yak> cat -b codes_test/var.c
1 /*
2 var.c
3 fichier simple qui affecte une variable
4 */
5 #include
6 int main()
7 {
8 int x;
9 x = 12;
10 printf("x = %d\ n", x);
11 return 0;
12 }
lysop@yak> ./eic -t codes_test/var.c
18,24,26,28,
5,
[main] 9,10,x = 12
11,
[::EiC::]
lysop@yak>
Figure 19. Exemple d'exécution de l'option trace avant modification
Comme on peut voir, la première série de numéros correspond aux instructions appelées par le
fichier « stdio.h » inclus. Le 5 correspond au début du fichier source « var.c » c'est-à-dire à l appel
de l include, puis on entre dans l appel de la fonction main(), puis les instructions des lignes 9
46

Analyse dynamique de programmes C
et 10 sont exécutées. L instruction 10 étant la fonction printf() qui affiche la valeur de la
variable x, son résultat est affiché après son numéro de ligne. L instruction de la 11 ème ligne du
code source est exécutée, elle correspond à la fonction return 0, puis on retourne dans
l environnement EiC ([::EiC::]) qui n a plus d instructions à exécuter d où la fin de son
exécution.
L option de trace originale à l interprète EiC ne nous fournit pas assez d informations quant à
l exécution du programme, mis à part le numéro des instructions exécutées. Nous allons alors
explorer le code source de EiC afin de savoir à quel endroit il y gère la fonction de trace, puis de
trouver comment la modifier afin qu elle nous renvoie les informations sur les dépendances entre
données.
Comme nous l avons vu dans le chapitre précédent, le code source de EiC est contenu dans le
dossier chemin_vers_EiC/src/ , le premier fichier appelé par le programme quand il est
exécuté etant « main.c ». Ce fichier fait appel à la fonction EiC_startEiC() définie dans le
fichier « starteic.c », qui fait appel à une autre fonction runEiC() pour initialiser l interprète EiC.
Elle effectue ensuite les analyses lexicale et syntaxique avant d exécuter la fonction
d interprétation EiC_interpret() qui, comme son nom l indique, effectue l interprétation des
instructions. Cette dernière fonction est définie dans le fichier « interpre.c », qui contient également
l option de trace d un programme vue en figure 19.
En effet, en suivant l enchaînement des appels entre fichiers sources EiC, nous trouvons que
l option de trace consiste en une exécution d instructions dans EiC_interpret() si la variable
EiC_traceON a pour valeur 1. Ainsi, lorsqu on fait appel à la commande eic t fichier.c,
la variable EiC_traceON est initialisée à 1 et la suite d instructions définies ci-dessous est
exécutée :
if(EiC_traceON) {
if(InSt[p].opcode == eiccall) {
EiC_eicpush(&names,v);
v.p.p = ((symentry_t *) STK[ToP - 1].v.p.p)->id;
EiC_formatMessage("\n[%s] ",(char*)v.p.p);
}
if(!EiC_traceFunc && lastln != InSt[p].line && InSt[p].line) {
lastln = InSt[p].line;
EiC_formatMessage("%d,",lastln);
}
}
Dans cet extrait de code source, les résultats de trace obtenus sous EiC sont effectués avec les
deux instructions : EiC_formatMessage("\n[%s] ",(char*)v.p.p), pour le nom de la
fonction exécutée et EiC_formatMessage("%d,",lastln) pour le numéro de la ligne
d instruction exécutée (variable lastln). Nous nous sommes donc servis de ces fonctions pour
y insérer nos propres informations, et nous avons aussi modifié leur format affichage en un
format spécifique à notre base de données (cf. section 5.14). Les informations que nous avons
ajoutées sont générées par la boucle d évaluation des instructions, qui est également effectuée à
l intérieur de la fonction EiC_interpret(). Cette boucle a pour rôle essentiel d exécuter le
code, qui à ce stade se présente sous la forme de code intermédiaire : opcode [operande], où
l opcope est un symbole désignant un type d instructions et operande désigne l éventuel
argument de l instruction. C est donc ce code intermédiaire que nous exploitons pour obtenir des
informations telles que l affectation d une variable ou son utilisation par une instruction.
Pour comprendre ce qu effectue la boucle d évaluation d instructions de la fonction
EiC_interpret(), il faut savoir au préalable que EiC décompose une ligne d instruction C en
plusieurs instructions de code intermédiaire. Nous pouvons voir dans l exemple qui suit,
47

Chapitre 5 - Description technique du travail réalisé
l utilisation de l option listcode de EiC qui permet de visualiser en mode interactif le code
intermédiaire généré pour toute instruction exécutée, nous avons également schématisé le rôle de
certains opcodes (pushint, stoint et rval) et de leurs opérandes :
EiC 4> x=5;
0:pushint 5
1:stoint 0 0
2:halt
5
Operandes
EiC 5> y=2;
0:pushint 2
1:stoint 1 0
2:halt
2
EiC 6> x;
0:rvalint 0 0
1: halt
5
Opcode
pushint
pushint
Pile
globale
5
stoint
stoint
2
5
Pile
globale
rvalint
5
0 1 2 3
0 5 2
1
3
Tableau AR
Les instructions EiC 4 et 5 effectuent des affectations de variables. Nous pouvons voir que
l affectation de variables entières est traduite par une suite de trois instructions de code
intermédiaire : pushint, stoint et halt. De la même manière l appel d une variable dans la
ligne d instruction 6 est traduit par deux instructions de code intermédiaire : rvalint et halt.
Chaque instruction de code intermédiaire est représentée dans EiC par la structure de données
suivante :
Typedef struct {
Unsigned opcode;
val_t val ;
int ext ;
unsigned short line ;
} InsT_t;
Cette structure permet donc d enregistrer pour chaque instruction le numéro de ligne (line), le
numéro d enregistrement de l objet 12 qu elle manipule le cas échéant (val), le niveau d appel de
l objet 13 (ext) et le code opérateur (opcode) qui la compose. Ainsi, deux codes opérateurs (ou
opcodes) peuvent appartenir à une même ligne d instruction C. EiC utilise également un
compteur interne d instructions (p) pour pouvoir les distinguer entre elles.
Nous pouvons voir ci-dessous un échantillon de code source, extrait de la fonction
EiC_interpret(), constituant la boucle d évaluation des instructions en pseudo code :
switch (InSt[p].opcode) {
case stoint: stoTYPE(ival); break;
case rvalint: rvalTYPE(ival); break;
}
12 Variable entière, chaîne de caractères, pointeurs, etc, stockés dans la table des symboles.
13 Global = niveau 0, local à main = 1, et ainsi de suite suivant la profondeur des appels.
48

Chapitre 5 - Description technique du travail réalisé
L instruction switch évalue l expression InSt[p].opcode, qui correspond au code opérateur
de l instruction de numéro d enregistrement p. Si le code opérateur est stoint alors la fonction
stoTYPE(ival) est exécutée, et ainsi de suite pour tous les codes opérateurs définis. Ces codes
opérateurs, ci-dessus, nous permettent de détecter lorsqu une variable entière est définie
(stoint), et pour détecter lorsqu une variable entière est utilisée (rvalint). L objectif de notre
outil étant d extraire les informations sur la définition et l utilisation des variables 14 , nous devons
principalement modifier la trace dans pour qu elle intègre ces informations. Par exemple pour le
programme de la figure 19, nous voulons obtenir une trace de la forme :
5,
[main]
9-
Def x 12 9
10-
Use x 9 10
x = 12
11-
return 0
[::EiC::]
Ce format nous permet ainsi de capturer l usage des variables effectué par chaque instruction de
notre exemple :
- en ligne 9 on définit la variable x avec la valeur 12 (Def x 12 9)
- en ligne 10 on utilise la variable x définie en ligne 9 (Use x 9 10), le résultat de
l instruction est affiché ensuite
- en ligne 11 on utilise la fonction return avec pour valeur de retour 0
Pour obtenir le format de base de données avec les lignes Use et Def, nous avons modifié le code
exécutépour le code opérateur stoint pour afficher une ligne de type Def. Par contre si c est
rvalint, alors nous affichons dans une ligne de type Use. Nous pouvons voir dans l extrait de
code source suivant comment cela a été introduit dans la boucle d évaluation d instructions :
switch (InSt[p].opcode) {
case stoint:
stoTYPE(ival);
printf("\tDef %d-%d %d %d \n",
InSt[p].ext,
InSt[p].val.ival,
AR[InSt[p].ext][InSt[p].val.ival].v.ival,
InSt[p].line);
break;
case rvalint:
rvalTYPE(ival);
printf("\tUse %d-%d %d %d \n",
InSt[p].ext,
InSt[p].val.ival,
lastcalline,
InSt[p].line);
break;
}
Une ligne de format Def contient trois informations : l identifiant de la variable, la valeur de la
variable et le numéro de ligne de l instruction C effectuant cette affectation. Une ligne de format
Use contient également trois informations : l identifiant de la variable, le numéro de ligne de
l instruction C et enfin la dernière ligne où la variable à été modifiée. La dernière ligne où la
14
Pour simplifier l exposé, nous nous concentrons ici sur l usage des variables, le cas des appels de fonctions est
détaillé en section 5.14.
49

Chapitre 5 - Description technique du travail réalisé
variable a été modifiée est obtenue grâce à la variable lastcalline, (surlignée en rose ci-dessus)
obtenue grâce à des modifications de la structure de la pile d exécution et à une nouvelle structure
d instructions que nous avons ajouté à EiC. Le détail de ces modifications est présenté en
sections 5.1.2.2 et 5.1.3.
L identifiant de la variable, comme on peut voir sur le code source ci-dessus, est une combinaison
de deux entiers : InSt[p].ext et InSt[p].val.ival (surlignés en bleu ci-dessus). Nous
donnons en section 5.1.2.1 un exemple permettant de mieux voir comment EiC identifie les
variables d un programme grâce à ces deux valeurs.
La valeur de la variable est accessible via la pile d exécution AR (runtime stack) définie dans
« eicval.h » (cf. annexe VII) grâce aux identifiants de la variable présentés en haut (cf surlignée en
jaune ci-dessus).
5.1.2.1. Identification des variables dans EiC
Pour comprendre le mécanisme d enregistrement des variables d un programme C par EiC, nous
nous regardons la base de donnée générée pour le programme « ext_affvar.c » donné en section
1.3 et redonné ci-dessous en plus version plus courte :
7 int m;
8
9 int main()
10 {
11 int x,y;
12
13 x = 12;
14 y = 8;
15 m = 15;
...
20 }
::EiC:: : 5 -> [main]
13.-
Def 1-0 12 13
14.-
Def 1-1 8 14
15.-
Def 0-2 15 15
Dans le code source m est définie en global, alors que x et y sont en local. Dans la base de
données générée par EiC, on peut voir qu en ligne 13 la variable x, qui prend la valeur 12, est
identifiée par 1-0. De même, aux lignes 14 et 15, y et m sont représentés par les identifiants 1-1
et 0-2. En effet, EiC identifie les variables par un couple « portée-numéro d ordre »: la portée de
niveau 0 correspond au niveau global, la portée 1 aux variables locales à une fonction de
contrôles et ainsi de suite pour les variables déclarées dans des blocs imbriqués, le numéro
d ordre est le numéro d enregistrement de la variable et commence par 0 pour la première
variable enregistrée. Ainsi, x est identifié par 1-0, puisqu il s agit de la 1 ère variable déclarée en
local à la fonction main(), y est identifié par 1-1, étant donné qu elle est la 2 ème variable
déclarée en local à main(), tandis que 0-2 identifie m qui est la 3 ème variable définie en global
(les deux premières positions sont réservées à des variables internes à EiC).
5.1.2.2. Enregistrement de la dernière ligne utilisant une
variable
Nous avons vu précédemment qu en cas de lecture de variable par une instruction nous
enregistrons une ligne de format Use dans la base de données, et que ce format doit contenir le
numéro de la dernière ligne d instruction C où cette variable a été modifiée. Pour cela nous avons
représenté ce numéro de ligne par la variable lastcalline. Nous voyons dans cette section
comment nous obtenons cette information ; pour cela nous reprenons le code de la section
50

Chapitre 5 - Description technique du travail réalisé
précédente et modifions la variable m pour qu elle reçoive la somme des valeurs des variables x et
y :
7 int m;
8
9 int main()
10 {
11 int x,y;
12
13 x = 12;
14 y = 8;
15 m = x+y;
...
20 }
::EiC:: : 5 -> [main]
13.-
Def 1-0 12 13
14.-
Def 1-1 8 14
15.-
Use 1-0 13 15
Use 1-1 14 15
Def 0-2 15 15
Pour représenter la lecture des variables x et y dans la base de données nous devons faire
référence au numéro de ligne où elles ont été affectées c'est-à-dire respectivement les lignes 13 et
14. Pour enregistrer ces deux valeurs, nous modifions la structure de la pile d exécution AR par
laquelle nous accédons aux valeurs des variables, en lui ajoutant un champ supplémentaire line.,
ci-dessous la structure de la pile d exécution ainsi modifiée :
typedef struct AR_t {
val_t v;
type_expr * type;
unsigned short line;
}AR_t;
Ce champ line nous permet ainsi à chaque modification de la valeur d une variable d enregistrer
le numéro de ligne où cela est effectué. Dans stoint et rvalint, nous avons ajouté une
ligne de code après chaque Def afin d affecter à la variable son nouveau numéro de ligne comme
on peut le voir ci-dessous :
case stoint:
stoTYPE(ival);
printf("\tDef %d-%d %d %d \n",
InSt[p].ext,
InSt[p].val.ival,
AR[InSt[p].ext][InSt[p].val.ival].v.ival,
InSt[p].line);
AR[InSt[p].ext][InSt[p].val.ival].line = InSt[p].line;
break;
5.1.3. Numérotation et compteur d appel des instructions
Nous abordons dans cette section la numérotation des instructions. En effet, ce point bien
qu abstrait à ce niveau et pouvant paraître sans grande importance à première vue est la clé dans
notre représentation des dépendances entre données.
Nous avons vu, dans l exemple donné en section 5.1.2, que lorsqu une variable est utilisée nous
avons besoin de savoir le numéro de la ligne d instruction où elle a été définie auparavant. Notre
numérotation des lignes doit non seulement permettre de faire des liens entre les données du
programme, mais aussi permettre d identifier de manière unique chaque passage sur une même
instruction(cf. l exemple donné ci-dessous). Ainsi, lorsqu on passe plusieurs fois sur une même
instruction (cas de fonctions récursives et boucles), nous devons générer autant d identifiants
d instructions que de passages.
51

Chapitre 5 - Description technique du travail réalisé
Pour en comprendre l importance, nous présentons dans ce qui suit un exemple de cas dans
lequel le simple enregistrement de la dernière ligne où une variable est modifiée (vu en section
5.1.2.2) est problématique :
1 int main()
2 {
3 int x;
4 x = 0;
5 while(x

Chapitre 5 - Description technique du travail réalisé
Nous avons par la suite créé un tableau de cette structure, l index du tableau étant le numéro de
ligne d instruction C appelée pendant l exécution du programme. Ce tableau est initialisé avant
l analyse du code intermédiaire de cette manière :
for (i=0; i

Chapitre 5 - Description technique du travail réalisé
Et ainsi de suite pour les deux derniers appels de boucle. En regardant les colorations des cases
du tableau 1, on remarque que les instruction de type Use font appel aux valeurs du tableau T
pour les valeurs dernier_appel et dernier_pass pour le numéro d instruction où la
variable 1-0 à été modifiée qu on peut alors obtenir via la variable AR[1][0].line.
Nous modifions la boucle d évaluation d instructions comme suit pour les codes opérateurs
stoint et rvalint :
case stoint: stoTYPE(ival);
AR[InSt[p].ext][InSt[p].val.ival].line = InSt[p].line;
printf("\tDef %d-%d %d %d %d\n",
InSt[p].ext,
InSt[p].val.ival,
AR[InSt[p].ext][InSt[p].val.ival].v.ival,
InSt[p].line,
T[InSt[p].line].cptr_a);
T[InSt[p].line].dernier_appel= InSt[p].line;
T[InSt[p].line].dernier_pass= T[lastln].cptr_a;
break;
case rvalint: rvalTYPE(ival);
printf("\tUse %d-%d %d %d %d %d \n",
InSt[p].ext,
InSt[p].val.ival,
T[AR[InSt[p].ext][InSt[p].val.ival].line].dernier_appel,
T[AR[InSt[p].ext][InSt[p].val.ival].line].dernier_pass,
InSt[p].line,
T[InSt[p].line].cptr_a);
break;
5.1.4. Extensions pour les boucles et l appel de fonctions
Dans cette section nous présentons les autres formats de la base de données pour les types non
encore cités tels que les évaluations de conditions, les appels de fonctions (telles que printf())
ou encore les fonctions main() et return() traitées différemment par EiC.
Pour capturer les appels de boucles et les structures de contrôles if, nous avons intégré à la
boucle d évaluation d instructions au niveau du code opérateur ltint l affichage d une
instruction Cond pour mettre en évidence dans notre base de données l évaluation d une
condition 15 dans le cas d un if ou de boucles while et for. Ainsi une ligne de format Cond 16
dans la base de données contient trois types d informations : la condition évaluée, la valeur de son
évaluation (0 ou 1) et les identifiants de la ligne d instruction.
Pour afficher l appel d une fonction, nous avons modifié le code opérateur call pour qu il
génère une ligne de format Call 17 dans la base de donnée, ce format contient alors deux types
d informations au plus : les identifiants de l instruction et la valeur de retour de la fonction le cas
échéant.
Pour afficher la fonction main(), nous lui avons réservé une ligne de format main 18 dans la
base de donnée, ainsi ce format de ligne renseigne les identifiants de lignes ou la fonction main()
est appelée dans le fichier source C.
15
Seul l opérateur « < » est traité par EiC à ce stade du projet.
16 Exemple : Cond (1

Chapitre 5 - Description technique du travail réalisé
Pour afficher la fonction return() nous avons modifié le code opérateur return pour qu il
génère une ligne de format Return 19 contenant deux informations : les identifiants de
l instruction qui l appelle et sa valeur de retour.
5.2. Affichage du graphique de dépendances entre
données
Nous voyons maintenant de quelle manière on exploite les informations de la base de donnée
générée pour obtenir une représentation graphique. Pour cela, nous commençons par présenter
l outil Dot de génération de graphes utilisé dans notre projet, puis nous décrivons le script
awk utilisé pour formater les informations de la base de données en un format utilisable par
Dot.
5.2.1. L outil dot
Cet outil [GAN 02] permet de générer des graphes contenant un grand nombre de n uds et
d arcs qui néanmoins reste clairs et aérés. Il offre de plus de larges possibilités pour la
représentation graphique : différentes figures pour les noeuds, différents types d extrémités d arcs,
couleur, styles de polices pour les labels de n uds et d arcs, par exemple. Il permet également de
générer les graphes dans des formats réutilisables comme entre autre le format PostScript. Nous
pouvons voir dans les figures ci dessous des exemples de graphes pouvant être générés avec cet
outil [BEL 05 ; GAN 02].
Figure 20. Exemples de graphes obtenus avec l outil Dot, avec un exemple de graphe en bas avec son code
source
19 Exemple : Return 0 10 1.
55

Chapitre 5 - Description technique du travail réalisé
Ainsi comme on peut le voir à la figure 20, créer un graphe de dépendance avec l outil Dot
nécessite d écrire au préalable les relations entre les n uds que l ont veut afficher dans un format
propre à l outil (n ud 1 -> noeud2). On qu on doit ainsi créer un fichier (en format .dot)
contenant toutes les définitions des n uds et des liens entre ces n uds, puis l exécuter avec la
commande dot suivante : dot -Tps -o fichier.ps fichier.dot
C est donc dans ce format Dot que nous allons formater notre base de données.
5.2.2. Formatage de la base de données au format dot
Dans cette section, nous présentons comment la base de donnée générée grâce à la version
modifiée de EiC est exploitée pour avoir une représentation graphique claire de nos dépendances
entre les données. Pour cela, nous avons utilisé les possibilités de l outil Dot pour représenter
chaque type d information de la base de données sous forme d un n ud ou d un lien dans le
graphe. Ainsi, chaque fonction (Call, main, Return) est représentée par un rectangle, rouge
pour la fontion main() et noir pour les autres, les définitions de variables (Def) sont
représentées par un n ud vert en forme d ellipse, l utilisation d une variable est représentée par
un line allant de la l igne d origine de sa valeur vers la ligne où elle est appellée. Les lignes
d instructions sont alors représentées par leur identifiant de ligne unique (numéro de
ligne:numero d appel) et alignées verticalement à gauche du graphe de dépendance, tel un
axe de mesure, par ordre d appel dans le programme. Nous pouvons visualiser cette
représentation graphique sur la figure 21, qui définit une variable x (identifiée par 1-0) puis
retourne sa valeur avec la fonction return.
var2.c
1 int main()
2 {
3 int x;
4 x = 12;
5 return x;
6 }
Figure 21. Graphe de dépendances dynamiques de données pour "var2.c"
Nous pouvons voir sur cette représentation graphique, que les n uds du graphe son positionnés
au même niveau que les identifiants de leurs ligne d appel sur l échelle d appel des instructions (à
gauche du graphe), sauf pour la fonction main qui est identifiée par son nom et son compteur
d appel. Ainsi, l échelle de gauche indique que le fichier analysé commence par la fonction main
et que la dernière ligne de code exécutée est la ligne 5:1 (end). Le graphe de dépendances à droite
de cette échelle nous indique que la fonction main (rectangle rouge) définit une variable en ligne
4:1 (ellipse verte), dont la valeur est renvoyée (fonction return) par l instruction de la ligne 5:1.
Les conditions des structures de controle telles que if et while, sont représentées par un noed
dans le graphe de dépendances en forme de losange, définit de sorte que si la condition est vraie,
56

Chapitre 5 - Description technique du travail réalisé
un lien vers l instruction suivante ira du sommet gauche du losange, et si la condition est fausse le
lien vers l instruction suivante ira du sommet droit. On peut voir ci-dessous un exemple de son
utilisation :
if (condition)
instruction_1
else
instruction_2
Condition
vraie
Condition
fausse
Instruction_1
Instruction_2
Figure 22. Propriétés du noeud représentant une condition.
Les scripts de nos graphes de dépendances sont générés de manière automatique à partir de la
base de données, grâce à trois scripts awk (cf. annexe VI) placés dans le dossier bin/ . Le
premier fichier se nomme « formaterdata.awk » et permet de supprimer des informations
superfluesextraites concernant l exéction interne à EiC. Le deuxième fichier se nomme
« graph1.awk » et permet de générer les premières lignes du script dot c'est-à-dire l entet du fichier
(en rouge sur la figure 23) et le code générant l echelle d enchainement des lignes d instructions
placée à gauche du graphe de dépendance (en bleu sur la figure 23). Le troisième script est
nommé « graph2.awk » qui génère le code dot adéquant suivant le type de ligne dans la base
donnée 20 , à savoir le type du n ud 21 , sa couleur, son comportement (dans le cas d une condition
par exemple) ou encore un lien reliant deux n uds (cas d un Use) . On peut voir à la figure 23 cidessous
un exemple de codes dot générés en fonction de la base de données obtenue pour le
programme « var2.c » donné en figure 21.
digraph G { ranksep=.75; size="7.5,7.5";
{ node [shape=plaintext, fontsize=16];
"main:1" -> "4:1" -> "5:1" -> "end"; }
{ rank = same;
"main:1"; "#main:1"; }
"#main:1" [label="main-1", shape=box, color=red]
var2.c :
# main:1
main 1
# 4:1
Def 1-0 12 4 1
# 5:1
Use 1-0 4 1 5 1
Return 12 5 1
"#main:1" -> "#4:1"
{ rank = same;
"4:1"; "#4:1"; }
"#4:1" [label="1-0=12", color=green]
"#4:1" -> "#5:1"
{ rank = same;
"5:1"; "#5:1"; }
"#5:1" [label="Return-1\n12", shape=box]
}
Figure 23. Code dot généré à partir de la base de données.
20
Use, Def, main, Return, Cond, Call.
21 Rectangle, ellipse, losange
57

Chapitre 5 - Description technique du travail réalisé
Sur la figure 23, on peut voir le détail du script dot ; chaque n ud est identifié par une chaine de
caractère entre guillemets, ainsi le n ud "4 :1" et différent du n ud "#4 :1". Nous nous sommes
servi de cette particularité du code Dot pour identifier les n uds de l échelle d instructions par
"x :y" et les n uds du graphe de dépendances par "#x :y", ce qui nous a permis de mettre chaque
n ud du graphe au même niveau que son correspondant dans l echelle (cf. codes dot encadrés en
bleu : rank=same; "5 :1"; "#5 :1";). Chaque n ud du graphe de dépendance est définit
par plusieurs critères tels qu une forme (rectangle, ellipse, etc.), un label (ce qui sera inscrit à
l intérieur de la forme) ou encore une couleur.
On peut également voir sur la figure 23, en première ligne (surligné en rouge) l entête du fichier
de script dot, suivi par le code générant l echelle de suite d instructions (cf. surligné en bleu). Les
lignes de scripts encadrées en bleu sont générées à chaque nouvelle ligne de base de donnée
commençant par le symbole «# ». Nous voyons ensuite que chaque ligne de base de donnée
génère la définition d un n ud avec le label correspondant à son type et/ou un lien entre deux
n uds (cf liens en violet). Ainsi, la ligne de base de donnée de type main gènère la définition du
n ud main comme un rectangle de couleur rouge de label « main-1 », puis relie ce n ud au
n ud suivant "# 4:1", de la même façon la ligne Use 1-0 4 1 5 1 génère un lien allant du
n ud "# 4 :1" ou la variable 1-0 à été définie, vers le n ud "# 5:1".
Comme nous venons de le voir, chaque ligne de la base de donnée est exploitée pour générer
suivant son type une série de codes dot pour définir l échelle de suite d instructions, le type de
n uds, et les liens entre ces derniers. Le graphe que nous générons ensuite par dot est en format
postscript, ils peuvent ainsi être visualisés sur bon nombre de plateformes.
58

Chapitre 5 - Description technique du travail réalisé
59

Analyse dynamique de programmes C
Chapitre 6 - Exemples de résultats
N ous avons vu au long des chapitres précédents des extraits de graphes de dépendances
dynamiques de données générés suivant le modèle de graphes de dépendances de l outil
DDFgraph pour le le langage Lisp (cf. chapitre 1). Ce chapitre, présente les résultats que nous
obtenons grâce à la technique de génération de graphe décrite dans le chapitre précédent, qui
présente les données de manière différente que pour le modèle suivi. Nous voyons dans ce
chapitre les résultats de graphes dynamiques de dépendances entre données obtenus pour
quelques exemples de programmes manipulant des variables entières. Nous présentons ces
résulats par ordre croissant de complexité.
6.1. Opérations sur des variables entières
Nous prenons pour premier exemple le fichier « ext_affvar1.c », qui effectue de simples opérations
sur des valeurs entières, retournant la valeur d une des variables manipulées en fin de programme.
1 /* ext_affvar1.c */
2 int g;
3 int main()
4 {
5 int x,y,a,b;
6 x = 12;
7 y = 8;
8 g = 15;
9 a = x + y;
10 x = a - g;
11 a ++;
12 return a;
13 }
Nous pouvons voir sur la figure 24 le graphe de dépendances
dynamique des variables entières manipulées par le programme
source. Nous avons ajouté, pour une meilleure lecture du graphe,
près de chaque n ud définissant une variable, le symbole
correspondant à l identifiant de celle-ci 22 .
En observant le graphe de plus près, nous pouvosn remarquer que
la variable b n est pas affichée sur le graphe, ceci est expliqué par le
fait que cette dernière n est pas manipulée pendant l exécution du
programme. Nous pouvons ainsi voir sur ce graphe les
dépendances entre les variables, comme par exemple la variable x
est définie en ligne 6 puis sa valeur est utilisée en ligne 9 pour
définir la valeur de la variable a, puis elle est encore modifiée en
ligne 10 en prenant une nouvelle valeur issue d une opération sur
les variables a et g.
Par contre il n existe pas de lien représenté entre les variables x, y et
g avec la fonction main dans laquelle ils sont définis, ce problème
d affichage est traité dans le chapitre 8.
x
y
a
a
g
x
22
Automatiserle rempalcement de l identifiant interne des variables par leur
symbole est l une de nos perspectives (cf. chapitre 8).
Figure 24. Graphe de
dépendances dynamique
60

Chapitre 6 - Exemples de résultats
Nous voyons dans ce deuxième exemple comment
l affichage graphique des dépendances dynamiques réalisé
peut mettre en évidence les variables non utilisées au cours
de l exécution de programmes.
1 /* isole.c */
2 int main() {
3 int x,y,z;
4 x = 1;
5 y = 5;
6 z = 3;
7 z += x;
8 return x;
9 }
Nous utilisons le code source ci-dessus définissant une
variable y sans l utiliser dans le reste des instructions, nous
pouvons alors visualiser le comportement des instructions
de ce programme sur la figure 25, la variable y identifiée par
1-1 (cf. ligne 5 du code source) est isolée des autres
instructions. Ceci peut nous permettre dans le cas de longs
programmes complexes d isoler les instructions qui n ont pas
de rôle dans l exécution du programme et de les éliminer afin
d améliorer le temps d exécution de ce dernier, d autant plus
si l instruction se trouve dans une boucle appellée un grand
nombre de fois.
6.2. Conditionnelles
Figure 25. Mise en évidence d'une
variable isolée
z
z
x
y
Nous voyons les résultats obtenus par notre programme pour la gestion d instructions à
conditions, en commençant par donner des exemples de graphes obtenus pour l instruction if,
puis nous montrons des graphes obtenus pour les boucles while, do..while() et for. Mais
avant d aborder ces exemples, il faut noter que seule la comparaison < est gérée par notre
programme.
6.2.1. L instruction if
6.2.1.1. Cas simples
Pour voir le comportement de programmes faisant appel à l instruction de contrôle if, nous
utilisons les deux programmes ci-dessous, le premier vérifie une condition vraie et le deuxième
vérife une condtion fausse et fait appel également à l instruction else, les représentations
graphiques de ces deux programm²es sont présentées à la figure 25.
if2.c
if1.c
1 int main (void){
2 int x;
3 x=6;
4 if (x

Chapitre 6 - Exemples de résultats
x
x
x
x
Figure 26. Graphes générés pour les fichiers "if1.c" cas où la condition est vraie à gauche et "if2.c" pour
un cas de condition fausse à droite.
Nous pouvons observer sur le graphique de gauche de la figure 26, que la condition du if (x

Chapitre 6 - Exemples de résultats
ifimbriques.c
Figure 27. Graphe de
dépendance pour l'appel de if
imbriqués « ifimbriques.c »
1 #include
2 int main (void){
3 int a,b,c;
4 a=6;
5 b=3;
6 c=5;
7 if (b

Chapitre 6 - Exemples de résultats
while.c
1 #include
2
3 int x;
4 int main (void){
5 x=0;
6 while (x

Chapitre 6 - Exemples de résultats
Figure 29. Graphe de
dépendances pour le code
x
x
do.c
1
2 int main (void){
3 int x;
4 x = 0;
5 do {
6 x++;
7 }while(x < 2);
8 return 0;
9 }
x
Au deuxième tour de boucle, les instructions qui y sont appelées
ont leur numéro de ligne avec un compteur d appel égal à 2, c està-dire
les lignes 6 :2 pour l incrémenattion de la valeur de x et la
ligne 7 :2 pour la condition du while. La deuxième évaluation de
la condition n étant pas vérifiée la ligne d instruction 8 :1 est
exécutée pour retourner la valeur 0.
6.2.4. Boucle for
for.c
b
i=0; i=1;
Pour l exemple de boucle for,
nous avons utilisé le programme
« for.c », qui fait deux tours de
boucles for et qui modifie la
valeur de la variable b (initialisée
à 5) à chaque tour de boucle en
fonction de la variable i. La
variable i étant l index de boucle.
1 int main (void){
2 int i,b;
3 b = 5;
4 for (i=0; i < 2; i++){
5 b += i;
6 }
7 return b;
8 }
b
b
i=2;
Nous voyons alors sur le graphe généré que les conditions dans
l appel de la boucle for sont correctement évaluées, les deux
tours de boucles sont bien effectuées et la valeur de b est
également bien modifiée. Cependant, bien que nous ayons les
bons résultats et les bonnes évaluations de conditions pour
chaque boucle, nous voyons que notre graphique se comporte de
manière innatendue. Il effectue en effet un retour sur chaque
appel de condition, ce qui n est pas le cas dans notre programme.
De plus, notre outil considère l initialisation et l incrémentation
de l index i ainsi que l évaluation de la condition, comme étant
effectués par une même instruction identifiée par la ligne du for
(4 :1, 4 :2, 4 :3 dans notre exemple). Or notre programme ne
i=3;
Figure 30. Graphe de
dépendances pour le code
65

Chapitre 6 - Exemples de résultats
prend pas encore en compte l exécution de deux instructions sur une même ligne. Il nous faudrait
alors trouver un moyen de gérer, au niveau de la numérotation de nos instruction les cas
d instructions sur une même ligne (cf. chapitre 8).
6.2.5. Boucles a imbriquées
imbriques.c
1 #include
2 int main(void){
3 int a,b,c;
4 b = 2;
5 a = 3;
6 c = 0;
7 do {
8 while (c < b){
9 c++;
10 }
11 b++;
12 } while (c

Chapitre 6 - Exemples de résultats
6.3. Appels de fonctions avec et sans arguments
Nous voyons dans cette section la manière dont sont représentés graphiquement les appels de
fonctions, définies dans un programme C. Nous commençons par présenter l exemple d un appel
d une fonction sans arguments, avec des variables qui lui sont locales, puis nous présentons un
deuxième exemple d appel d une fonction avec arguments.
6.3.1. Fonction sans arguments
Nous utilisons le programme « foncssarg.c » pour présenter le cas d un appel d une fonction sans
argument. Ce programme commence par définir la fonction add23() qui aditionne deux
variables entières, définies en local, de valeur 2 et 3, puis retourne leur somme. La fonction
main() est définie ensuite et ne fait que retourner le résultat de l appel à la fonction add23().
foncssarg.c
x
y
1
2 int add23 (void) {
3 int x,y;
4 x = 2;
5 y = 3;
6 return x+y;
7 }
8
9 int main(void) {
10 return add23();
11 }
On peut voir sur la figure 32 le graphe de
dépendances généré pour ce programme.
La fonction add23() est ainsi appelée en
premier en ligne 10 :1, ses variables locales
sont définies aux lignes 4 :1 et 5 :1 et sont
identifiées par 1-0 pour x et 1-1 pour y.
Nous voyons également sur cette figure, que la fonction add23-1
n est pas reliée à la fonction Return-2. Ceci est en effet dû au fait
que nous ne générons pas encore d informations dans notre base de
données pour relier la fonction appelée à l instruction l appelant, ici
Return-1 de la fonction add23-1 devrait être reliée à Return-2
(cf. lien en pointillés rouges). Nous verrons au chapitre 8 comment
nous pouvons remédier à cela.
Figure 32. Graphe de
dépendances de données
pour "foncssarg.c".
De plus, contrairement au cas du for, l appel d une fonction dans
une instruction est considéré comme la succession de deux
instructions : d abord l appel de la fonction puis l instruction ellemême.
Ici la fonction add23() est exécutée en ligne 10 :1 et lorsque la
fonction fait appel a sa valeur de retour, le compteur d appel de
l instruction 10 est incrémenté au lieu de rester à 1.
67

Chapitre 6 - Exemples de résultats
6.3.2. Fonction avec arguments
Nous voyons maintenant comment l appel de fonctions avec arguments est représenté
graphiquement, puis ce que l on obtient dans la base de données grâce à la version modifiée de
EiC. L exemple qui suit utilise le programme « foncavcarg.c » qui définit deux variables entières dans
la fonction main(), ces valeurs sont alors passées en argument à la fonction add23().
a
b
x,y
Figure 33. Graphe de dépendances
de données généré pour le
programme "foncavarg.c".
foncavcarg.c :
# main:1
main 1
# 7:1
Def 1-0 2 7 1
# 8:1
Def 1-1 3 8 1
foncavcarg.c
# 9:1
stoval -3- stoval -2- eiccall
1 int add23 (int x,int y) {
2 return x+y;
3 }
4
5 int main(void) {
6 int a,b;
7 a = 2;
8 b = 3;
9 return add23(2,3);
10 }
Nous pouvons voir sur cet exemple les définitions des
variables a et b de la fonction main() aux lignes 7 :1 et 8 :1,
qui sont suivies du premier appel à la fonction add23 en ligne
9:1. Nous pouvons remarquer qu à cette même ligne un n ud
est relié à la fonction Return-1 de la ligne 2 du code source et
qui retourne bien la somme des valeurs des arguments à la
fonction add23(). Ainsi, les arguments x et y sont
représentés par un n ud unique : le noeud « #1:629592 »,
dont le 1 signifie que ces variables sont définies en ligne 1 du
code source et le chiffre 629592 correspond au nombre
d appels de cette ligne, cette valeur est à priori fausse puisqu il
s agit du premier appel à la fonction add23 définie en ligne 1.
Ceci étant, les liens partant de ces variables x et y vers la
fonction Return-1 sont correctement affichés.
En regardant de plus près la base de données (donnée cidessous)
générée avec EiC nous pouvons voir que ces deux
variables sont identifiées au niveau 1 et numérotées négativement 23 c est-à-dire que la variable x
est identifiée par 1- -1 et y par 1- -2 (cf. surlignés en rouge dans la base de données) et leurs
valeurs sont transmises à la fonction grâce au code opérateur stoval (cf. surlignés en jaune cidessous),
comme nous pouvons le voir ici :
foncavcarg.c :
Fonc add23 9 1
# 2:1
Use 1--1 1 629592 2 1
Use 1--2 1 629592 2 1
Return 5 2 1
[main]
# 9:2
Return 5 9 2
[::EiC::]
23 Les variables passées en argument à une fonction sont numérotées négativement par EiC.La numérotation
commence par -1 pour le premier argument, -2 pour le suivant et ainsi de suite.
68

Chapitre 6 - Exemples de résultats
Les valeurs surlignées en jaune et en rouge ne sont pas représentées dans notre graphique, il
faudrait donc trouver un moyen de les afficher.
Nous avons également réfléchi sur les cas d affichage de tableau, mais nous n avosn aps encore
de représentation graphique de ce type de donnée, nous sommes cependant arrivés à reconnaître
la série de codes opérateurs intervenants pour la définition d un élèment du tableau. Nous voyons
au chapitre 8 comment exploiter ces informations pour représenter les tableaux dans notre
graphe de dépendances ?
Nous avons donc vu ce que l on peut déjà représenter avec notre outil d analyse dynamique basé
sur l interprète EiC, à savoir l affichage pour :
- Les séquences d instructions, grâce à l échelle d enchainement des lignes d instructions.
- Les dépendances entre données manipulées par les instructions.
- Les boucles grâce à notre numérotation unique des lignes d instructions.
- Les conditionnelles représentées par un n ud dont le comportement change suivant que
la valeur de la condition.
Tout cela donne un aperçu de ce que l on pourrait faire en étendant les fonctionnalités de notre
outil, nous verrons dans le chapitre des perspectives (chapitre 8) l ensemble des améliorations
pouvant encore être apportées à notre outil dans ce sens.
69

Analyse dynamique de programmes C
Chapitre 7 - Comparaison avec l existant
Il existe à l heure actuelle de nombreuses recherches portant sur le domaine de l analyse
dynamique de programme. Certains travaux de recherche ont même permis de développer des
outils dont les résultats sont encourageants quant aux objectifs de ces recherches. Je vais
présenter dans ce chapitre, quelques projets traitant de l analyse dynamique de programmes et
apportant une solution pour visualiser les dépendances entre données extraites.
Dans le domaine de la recherche, nous pouvons citer les travaux de Systä sur l analyse dynamique
de programmes objets (Java) [SYS 01]. Le concept de dépendances dynamiques fû introduit par
Korel et Laski [KOR 88] dans le contexte du slicing dynamique, qui consiste à connaitre les
valeurs des variables dont la valeur dépend directement d une variable donnée. Le concept de
graphes de dépendances dynamiques a été introduit par Agrawal et Horgan [AGR 90] qui se base
sur des algorithmes pour calculer les slices dynamiques. Ces algorithmes utilisent un historique de
l exécution pour extraire les informations sur les slices concernés. Ces techniques sont
essentiellement intégrées dans des programmes tels que les débuggeurs, qui permettent d obtenir
les valeurs des variables pendant l exécution du programme ; ces valeurs sont visualisables de
façon textuelle et non graphique. Du fait de l importante masse de données générée par ces
techniques, des études se sont orientées pour trouvers des solutions de compactages des données.
Notre projet, intègre le calcul dynamique et la représentation graphique des dépendances de
données. Il permet de tracer non seulement les dépendances d une variable mais l ensemble des
interactions des données manipulées par le programme.
Dans le reste du chapitre, nous présentons en section 7.1 l outil Call graph d aide à la
maintenance de programmes C. Le deuxième outil, Zeugma, que nous présentons en section 7.2,
propose une approche originale de représentation des données. Et le dernier outil, Care, que nous
présentons dans la section 7.3, représente la solution la plus proche de notre outil.
7.1. Call graph Drawing interface
L outil Call Graph Drawing Interface [ENG 03] est une solution permettant d afficher le graphe
de dépendances des appels de fonctions pour des codes sources C et C++ sous Unix. Le
graphique des dépendances des appels est généré pendant l exécution du code source par le
compilateur avec les options p et g de GCC. Il utilise ainsi l outil de profiling de programmes
Gprof [FEN 97], pour extraire les données dynamiques du code source et l outil VCG [SAN 95]
pour afficher ces dépendances graphiquement.
Nous pouvons voir ci-dessous un exemple d affichage des dépendances dynamiques des
interactions entre les fonctions d un programme C++ donné également dans cette figure.
70

Chapitre 7 - Comparaison avec l existant
#include
class A {
public:
void a();
void b();
void c();
};
void A::a(){b();}
void A::b(){}
void A::c(){}
int main()
{A t;
t.a();
t.c();
exit(0);}
Figure 34. Graphe de dépendance des fonctions du fichier "test.cpp" à gauche de la figure
Nous pouvons voir dans cet exemple, que la fonction main fait appel à trois fonctions. La
première fonction a() est définie dans la classe A et fait appel à la fonction b() qui est est
définie dans cette classe. La deuxième fonction c() est également définie dans A et la troisième
est la fonction exit(0). Sur le graphe généré dynamiquement, on peut voir des liens de la
fonction main vers les deux fonctions de classe A, avec le lien représentant l appel de la fonction
a() à la fonction b() et enfin un lien de la fonction main vers la fonction exit. Nous n avons
donc aucune représentation sur la valeur passée en argument à la fonction exit, contrairement à
notre outil qui permet de retourner ces valeurs graphiquement.
L appel à Gprof permet de consulter le contenu du fichier de données généré, des options
d appel à cet outil permettent de filtrer les données qu on veut consulter (par exemple choisir de
ne pas représenter certaines fonctions). Le fichier de données doit ensuite être manipulé par
d autres outils pour le mettre sous un format spécifique lisible par VCG. Il n y a, de plus, aucune
automatisation de cette génération de graphes.
Donc cet outil, tout comme le nôtre, permet d obtenir une visualisation de données extraites de
manière dynamique d un code source. L avantage que présente Call Graph est que toutes les
spécificités du C sont prises en compte étant donné que le compilateur gcc est utilisé. Cependant,
les informations extraites ne concernent que les dépendances entre fonctions, ce qui ne donne au
développeur qu une partie de l information manipulée par un programme. Notre programme
permet non seulement de générer un plus grand nombre d informations d un code source exécuté
mais se base sur un interprète, portable sur un grand nombre de systèmes. Il offre également une
génération automatique des graphes de dépendances.
7.2. Zeugma : représentation métaphorique de
programmes
L outil Zeugma [PLO 02], développé par D. Ploix en Intelligence Artificielle, porte sur la
représentation analogique de programmes en Vlisp. Il est basé sur des liens métaphoriques entre
les objets manipulés dynamiquement par un programme et des domaines de représentations dans
des villes ou encore des comportements d animaux lors de l exécution du programme, ces liens
sont activés pour ainsi construire une représentation métaphorique du programme.
71

Chapitre 7 - Comparaison avec l existant
Nous pouvons voir sur les exemples des figures 35 et 36 chacune de ces représentations :
Figure 35. Représentation en ville à gauche, détail d une maison à plusieurs étages en haut à droite et
d une maison contenant d autres maisons en bas à droite
Figure 36. Représentation en toile d'araignée à gauche et détail d une araignée à droite
La figure 35, présente l exemple d une visualisation d un programme sous forme d une ville.
Chaque quartier de la ville correspond à un type de données identifié par sa couleur : les boules
(en rouge), les conditions (en orange), les additions de nombres (en bleu) pour notre exemple.
Chaque quartier est composé de rues reliant plusieurs maisons pour traduire les interactions entre
données. Chaque maison est composée d étages (cf. figure), plus elle a d étages plus la fonction
72

Chapitre 7 - Comparaison avec l existant
qu elle représente est complexe, elle peut également contenir d autre maisons pour les appels
récursifs.
La figure 39, représente les interactions entre fonctions et variables comme des interactions entre
araignées sur une toile, chaque araignée représentant une fonction du programme. A la fin de
l exécution, plus les araignées sont proches plus les interactions entre les données qu elles
représentent sont importantes.
Cet outil, permet de se construire une idée assez précise du comportement d un programme, mais
il ne permet pas de connaître les valeurs manipulées par le programme ni de suivre le contrôle de
son exécution.
7.3. CARE
Le projet CARE (Computer-A ided Re-Engineering) [LIN1 93, LIN2 93] est issu des recherches
effectuées au sein du Laboratoire du Département Informatique de l Université Technologique
du Tennessee (Etats-Unis) et ceci depuis 1990. Ce projet vise à développer des prototypes
d outils d aide à la compréhension, à la maintenance et à la création de programmes.
Ces travaux se sont basés sur deux outils appelés VIFOR (Visual Interactive Fortran) et VIC
(Visual Interactive C), développés dans les années 80 par des membres de l équipe de recherche
de l Université Wayne State à Détroit (Michigan). Les outils actuellement développés par l équipe
du projet sont au nombre de trois :
- CARE est un outil pour la compréhension et le développement de gros programmes en
ANSI C
- OO!CARE est la version orientée objet de CARE, qui facilite la compréhension et la
maintenance de programmes écrits en C++
- PolyCARE est le fruit des derniers travaux de recherche de l équipe CARE. Cet outil se
concentre sur l aide à la compréhension de programmes complexes écrits en différents
langages.
L outil CARE est donc assez proche de par sa description aux objectifs de notre travail, mais
voyons de plus près l étendue des possibilités qu offre ce logiciel aux développeurs.
Cet outil permet d obtenir la représentation graphique de quatre types de données :
- une représentation textuelle (cf. figure 37)
- une représentation sous forme de colonnes de types de données (cf figure 38)
- une représentation de graphe hiérarchique des dépendances entre données (cf. figure 39)
- des représentations de slicings (cf. figure 40)
Ces différentes représentations de données sont générées après analyse du programme source,
qui extrait dans une base de données les informations sur les interactions entre les données du
programme. L ensemble de ces représentations est généré via une interface graphique, comme
nous pouvons le voir sur les figures qui suivent.
73

Chapitre 7 - Comparaison avec l existant
Figure 37. Représentation textuelle d'un programme C
Figure 38. Représentation en collonnes
74

Chapitre 7 - Comparaison avec l existant
Figure 39. Représentation hiérarchique des appels de fontions du programme de la figure 37
Figure 40. Représentation graphique d'un slice de la fonction Get Number
Comme nous pouvons voir sur ces figures, les données des variables manipulées ne sont pas
représentées, contrairement à notre outil. CARE se présente donc comme un outil complet pour
l analyse statique de programmes C, et permet grâce à son interface de visualiser un ensemble de
représentations permettant ainsi au developpeur d avoir une meilleure connaissance du
programme. Notre outil permet de représenter le graphe de hiérarchie, de la même manière que
CARE, mais en se basant sur une analyse dynamique ce qui le rend plus précis.
De plus, CARE fonctionne sur des machines DEC et des stations de travail HP avec un système
Unix avec un X-based Motif GUI. Contrairement à notre outil qui peut être utilisé sur
différentes plateformes (cf. section 3.4).
Ainsi, notre outil d analyse dynamique de programmes C, apporte grâce à sa base d analyse
dynamique de programme la possibilité d avoir une trace précise des dépendances entre données,
ce que n offre aucun des outils présentés dans ce chapitre, bien qu ils permettent d avoir une idée
du fonctionnement d un programme à partir de son code source.
75

Analyse dynamique de programmes C
Chapitre 8 - Conclusion et perspectives
Pour conclure, nous résumons dans un premier temps ce qui a été vu tout au long de ce
mémoire, puis nous présentons les perspectives pour notre projet d analyse dynamique de
données, avec toutes les améliorations pouvant à terme faire que cet outil soit une réelle aide pour
les développeurs du langage C.
Nous avons présenté dans les premiers chapitres l intérêt de ce projet, à savoir permettre aux
programmeurs de connaître la trace des programmes C qu ils développent ou qui ont été
développés par un tiers et dont la taille en lignes de codes est trop importante pour en
comprendre aisément le fonctionnement. Ainsi, exploiter le programme source pendant son
exécution pour en générer une représentation graphique des dépendances des données qui y sont
manipulées, permet d apporter des informations précises sur le comportement du programme.
Ceci peut également aider le programmeur à détecter des disfonctionnements dans le
déroulement de son exécution, notamment lorsque le programme se comporte de manière
différente de celle recherchée par son concepteur tout en donnant un résultat correct. La
représentation graphique des dépendances entre les données d un programme peut également
aider les développeurs dans leur travail d optimisation de code.
Pour réaliser notre programme d analyse dynamique de programmes C, nous nous sommes basés
sur le prototype DDFgraph qui génère des graphes dynamiques de dépendances pour des
programmes Lisp et qui a été réalisé en modifiant un interprète Lisp. Modifie un compilateur C
représentant un travail considérable, difficile à envisager dans le cadre de ce projet. Nous avons
alors cherché un interprète du langage C dont la modification était plus abordable. Puis nous
avons testé les différents interprètes C existant dans le domaine public, EiC qui s est alors avéré le
plus conforme à nos attentes.
Nous avons alors entrepris d en comprendre le fonctionnement, pour ensuite modifier son
option de trace afin qu elle génère plus d informations que dans sa version initiale. Nous avons
alors pu obtenir grâce à cette technique des informations telles que les dépendances entre
variables entières, les appels de fonctions, les conditions et les boucles. Nous avons enregistré ces
informations dans une base de données que nous avons ensuite exploitée à l aide d un script awk.
Puis nous avons utilisé certaines fonctionnalités de l outil Dot pour obtenir un affichage
graphique des dépendances entres les données, avec une échelle d enchaînement des instruction
et quelques règles d affichage. Nous avons également automatisé la génération de base de donnée
ainsi que du graphe grâce à un script Shell.
Notre technique d extraction dynamique de données basée sur l interprète EiC, présente des
avantages tels qu une possibilité de gestion de l ensemble du langage C, et la possibilité de
portabilité de notre outil sur un bon nombre de systèmes. De plus, l automatisation de la
génération des graphes, avec le script Shell, rend notre outil simple d utilisation. La représentation
graphique suivant une échelle d exécution des instructions, permet au développeur de tracer
visuellement son code source de manière très précise.
Bien que notre outil soit fonctionnel pour des cas simples de programmes C, il présente des
limites que nous voyons en section 8.1. Nous voyons également à la section 8.2 quelques
améliorations possibles à notre outil, puis nous concluons en présentant les perspectives pour ce
projet.
76

Chapitre 8 - Conclusion et perspectives
8.1. Limites de notre outil d analyse dynamique de
programmes C
Notre outil, comme nous l avons vu tout au long de ce mémoire, présente des limites de
différents ordres. En effet, notre outil, puisque basé sur les informations extraites par l interprète
EiC nous limite pour les capacités de ce dernier. Comme nous l avons montré au chapitre 3, EiC
est le seul interprète du domaine public qui soit actuellement capable de prendre en charge
l ensemble des spécificités du langage C, mis-à-part la librairie standard du C . De plus,
l outil EiC n étant plus développé depuis 2000, sa documentation n étant de plus pas finie, nous
devons en comprendre le fonctionnement par nos propres tests et analyses.
Mis à part ces légères limites dues à l interprète utilisé, nous avons relevé d autres limites. Nous
en énumérons les plus importantes ci-dessous :
Notre outil ne prend pas en charge toutes les sépcificités du langage C, il n est donc pas
encore capable d analyser des instructions switch, les structures, les unions, les pointeurs,
ou encore les fonctions récursives.
Notre numérotation des lignes d instructions n est pas encore au point pour gérer les cas
complexes d instructions.
Notre base de données ne contient pas encore toutes les informations pour pouvoir
établir des liens spécifiques entre les données, tels que les liens entre les variables locales
et la fonction dans lesquels elles sont définies. Seule la première variable est reliée à la
fonction actuellement.
La représentation graphique des dépendances entre données ne représente pas toutes les
règles de dépendances entres les données d un programme C. L affichage des appels de
fonctions et des tableaux n est pas encore bien géré.
Nous présentons dans la section 8.3.1 les améliorations possibles pour le premier point, les
améliorations concernant les second et troisième points sont abordées à la section 8.2.2 et enfin,
le troisième point est traité dans la section 8.2.3.
8.2. Améliorations possibles
Dans cette section nous voyons quelles améliorations peuvent être apportées à notre outil, dans
les prochains travaux ainsi que les améliorations pouvant rendre notre outil à terme plus complet.
8.2.1. Prise en charge des spécificités du langage C
Pour que notre outil puisse analyser tout programme C, nous devons étendre ses capacités de
gestion des autres caractéristiques du langage C. Les extensions les plus simples à faire dans un
premier temps consistent à reproduire le modèle de génération de lignes de base de données au
format Def et Use pour les variables entières, pour les autres types. Pour cela, il suffit d ajouter
77

Chapitre 8 - Conclusion et perspectives
dans les codes opérateurs nommés rval 24 une ligne de
printf(« Use... ), et une ligne de printf(« Def ) pour ceux dont le nom est de la
forme sto 25 . Il suffirait alors d adapter le format des valeurs
retournées par le printf à celles manipulée par le code opérateur chaine de caractère (par
exemple printf(« ..%s..,..,variable de type char );).
Un autre point d extension nécessitant de reproduire ce que nous avons déjà fait concerne les
opérateurs de comparaisons. En effet, notre outil n affiche les n uds de conditions que pour
celles effectuant une comparaison entre deux entiers avec l opérateur «< ». Pour étendre cela aux
autres opérateurs du C, il suffit d insérer un printf générant une ligne de type Cond, pour la
base de données, dans tous les codes opérateurs gérant des entiers dans un premier temps
nommés tels que leint pour

Chapitre 8 - Conclusion et perspectives
rvalint (cf. section 5.1.2.2) mais cette fois-ci pour l appel d une fonction, effectué par le code
opérateur eiccall. Notre graphe doit également être amélioré pour afficher ce type de lien qui
pourrait d ailleur avoir une couleur spécifique.
Il faudrait également tester le comportement de notre système de numérotation pour les cas
d appels de fonctions récursives, et adapter ce dernier aux cas d appels complexes.
Il serait également intéressant d intégrer la structure d instruction que nous avons introduit dans
le code source de EiC (cf. section 5.1.3), aux structures de données existantes donc gérées par
EiC, ceci nous éviterait de devoir pré-initialiser les compteurs d appels pour un nombre défini
d instructions, alors que EiC n impose aucune limite quant au nombre d instructions exécutables.
8.2.3. La représentation graphique
Notre représentation graphique affiche, dans le cas de deux variables définies dans une fonction,
un lien du nom de cetet fonction vers la première variable définie (cf.exemple de la figure 24).
Pour remédier à ce problème d affichage, nous devons améliorer notre script awk pour qu il
génère un lien entre la fonction et chacune des variables qui y sont définies localement.
Un autre point à améliorer dans la représentation graphique est l affichage des informations sur
les variables passées en argument, car nous avons dans la base de données les bons identifiants de
ces variables mais ceux-ci sont considérés sur le graphe généré comme une seule variable (cf.
section 6.3.2). Nous récupérons également leurs valeurs dans la base de données mais ces
dernières ne sont pas encore représentées dans le graphe de dépendances de données.
Comme nous l avons vu dans le chapitre 6, le graphe que nous générons suit une échelle
d enchaînement des instructions suivant leur exécution. Ceci peut générer des graphes en hauteur
et nous amener à parcourir le graphe tel un code source, ce qui pourrait être également fastidieux
pour des codes avec un grand nombre de lignes d instructions. Il faudrait alors s inspirer du
travail réalisé pour l outil DDFgraph pour compacter l affichage [BAL 03], ou encore permettre
au développeur de générer des graphes pour des sections de code source avec les autres
instructions représentées en un seul n ud, par exemple.
8.2.4. Vers un outil complet d analyse dynamique
Notre outil devra à terme être capable d afficher le graphe de tout programme C, avec la gestion
des cas d instructions complexes (comme par exemple le cas d une condition contenant l appel à
une fonction pouvant de plus être récursive).
Pour cela, nous devons d une part étendre ses capacités en se basant sur la base de données
générée actuellement, pour en extraire des graphes de dépendances plus spécifiques pour
représenter les dépendances entre les variables manipulées ou entre fonctions appelées. Nous
devons d autre part, créer de nouvelles bases de données sépcifiques à des structures, des
pointeurs ou encore des tableaux avec les valeurs qui leur sont affectées pendant l exécution du
programme.
Nous envisageons également de réaliser une interface graphique à notre outil, permettant ainsi à
l utilisateur de charger son code source, et de choisir suivant ses besoins le type d affichage voulu,
79

Chapitre 8 - Conclusion et perspectives
ainsi que la suite d intructions qu il veut tracer. Il pourra alors visualiser un graphe condensé pour
les instructions non séléctionnées avant l exécution du code source mais par contre le détail de
celles choisies. Cette représentation graphique serait affichée dans une fenêtre adjacente à celle du
code source, comme c est le cas pour l outil JFL C (cf. section 3.3).
A terme, nous envisageons d intégrer à cette interface la possibilité de visualiser le graphe de
dépendance en temps réel pendant l exécution du code source C, offrant ainsi au developpeur la
possibilité d arrêter cette exécution à tout instant et d éxaminer en détail les valeurs en cours de
manipulation. Nous y intégrerons également une option de recherche suivant le numéro de ligne,
de mots clés, ou encore de type de n uds, qui permettera de mettre en évidence sur le graphe de
dépendances les résultats de la recherche sous un format visuellement repérable, en coloriant les
n uds trouvés avec leurs liens avec une couleur spécifique par exemple.
Gageons qu un tel outil sera alors aussi indispensable qu un débuggeur à l heure actuelle.
80

Analyse dynamique de programmes C
Bibliographie
[AGR 90]
[BAL 05]
[BAL 01]
[BAL 00]
[BAL 03]
H. Agrawal and J. Horgan, Dynamic program slicing
Proceedings of the ACM SIG PLAN 90, Conference on Programming Languages
Design and Implementation, White Plains (New York), 1990.
Françoise Balmas, Harald Wertz and Rim Chaabane, Visualizing dynamic data
dependences as a help to maintain programs
International Conference on Software Maintenance, poster session, Budapest
(Hungary), 2005.
Françoise Balmas and Harald Wertz, Identifying information needs for program
understanding: an iterative approach
7 th Int. Conf. on Reverse Engineering for Information Systems, Lyon
(France), 2005.
Françoise Balmas and Harald Wertz, Identifying information needed to understand
programs: preliminary observations
Research Report, University Paris 8, St Denis (France), July 2000.
Françoise Balmas, Displaying dependence graphs: a hierarchical approach
Journal of Software Maintenance: Research and Practice, 00:1-37, 2003.
[BEL 05] Fares Belhadj, Outils pour développeurs : Graphviz Dot
Support de cours, Université Paris 8, St. Denis (France), 2005.
[BRE 98]
[BRE 00]
[BRE 03]
[DEL 03]
[DON 03]
[ENG 03]
[FEN 97]
Neil V. Brewster, Creation of a Software Bookshelf for the Linux operating system
Thesis for the degree Bachelor of Applied Science, University of Toronto,
Toronto (Canada), 1998.
Edmon J. Breen, The embeddable/ extensible interactive, pointer-safe, bytecode C
interpreter/compiler
http://eic.sourceforge.net/index.html, 2000.
Edmond J. Breen, Extensible Interactive C
http://eic.sourceforge.net/documentation/, January 2003.
Claude Delannoy, Langage C
2 ème edition, Eyrolles, Paris, 2003.
Steve Donovan, The UnderC Development Project
http://home.mweb.co.za/sd/sdonovan/underc.html, 2001-2003.
Vadim Engelson, Call Graph Drawing Interface
http://www.ida.liu.se/~vaden/cgdi/, 2003
Jay Fenlason and Richard Stallman, Gprof: The GNU profiler
http://www.gnu.org/software/binutils/manual/gprof-
2.9.1/html_mono/gprof.html, 1997.
82

Analyse dynamique de programmes C
[GAN 02]
[GOT 05]
[GRE 97]
[GRU 00]
Emden Gansner, Eleftherios Koutsofios et Stephen North, Drawing graphs with Dot
http://www.graphviz.org/pub/scm/graphviz2/doc/info/lang.html, 2002.
Masaharu Goto, Rene Brun et Fons Rademakers, The Cint C/C++ Interpreter
http://root.cern.ch/root/Cint.html, 2005.
Patrick Greussay, Cours d Intelligence A rtificielle
DEA IAOC, Université Paris8, St. Denis (France), 1997
Dick Grune, Henri E. Bal, Ceriel J.H. Jacobs, Koen G. Langendoen, Compilateurs
Édition Dunod, Paris, 2000.
[HAT 97] L. Hatton, Does OO sync with the way we think ?
IEEE Software, Vol. 15, No. 3, p. 46-54, May/June 1998.
[JAH 00]
[KOR 88]
[LUC 05]
[LAN 05]
[LIN1 93]
[LIN2 93]
[PLO 02]
[RIF 02]
[SAN 95]
[SOF 05]
Erwan Jahier, A nalyse dynamique de programmes: mise en uvre automatisée d analyseurs
performants et spécifications de modèles d exécution
Thèse de doctorat, INSA de Rennes, Rennes (France), 2000.
B. Korel and J. Lasky, Dynamic program slicing
Information Processing Letters, 29(3), p. 155-163, October 1988.
Jean François Lucas, JFL C interprète
http://jflucas.club.fr/Philotechnique/PresentationGeneDeLInterprete2.htm,
2005.
Présentation de l analyse dynamique du projet LANDE.
http://www.irisa.fr/lande/jensen/ap.html, 2005.
P. Linos, P. Aubet, Laurent Dumas, Y. Helleboid, P. Lejeune & P. Tulula,
Facilitating the Comprehension of C Programs: An Experimental Study
Proceeding of the Second IEEE Workshop on Program Comprehension, Capri
(Italy), p. 55-63, July 1993.
P. Linos, P. Aubet, Laurent Dumas, Y. Helleboid, P. Lejeune & P. Tulula, CARE:
An environment for Understanding and Re-engineering C Programs
Proceeding on Program Comprehension, Montreal (Canada), p. 130-139,
September 1993.
Damien Ploix, Analogical Representations of Programs
First IEEE International Workshop on Visualizing Software for Understanding
and Analysis, p 61-69, June 2002.
Jean-Marie Rifflet, La programmation sous UNIX
3 ème édition, Ediscience, Paris, 2002.
G. Sander, VCG: Visualization of Compiler Graphs
Universitaet des Saarlandes, Saarbruecken (Germany), February 1995.
SoftIntegration Corporation, CH Standard Edition
http://www.softintegration.com/products/chstandard/, Copyright 2001-2005.
83

Analyse dynamique de programmes C
[SYS 01]
[WIN 72]
T. Systä, An environment for reverse engineering of java software systems
Softare Practice and Experience, 31(4), p 371-394, 2001.
Terry Winograd, Understanding Natural Language
Academic Press, New York (New York), 1972.
84

Analyse dynamique de programmes C
85

Analyse dynamique de programmes C
Annexes
ANNEXE - I - PROGRAMMES DE TESTS DES INTERPRETES C ET TRACES DE TESTS .....................88
ANNEXE - II - COMMANDES INTERNES A EIC EN MODE INTERACTIF ..........................................91
ANNEXE - III - DIRECTIVES D APPEL A EIC EN MODE BATCH......................................................93
ANNEXE - IV - SCRIPT SHELL "EIC_ADPC.SH ..............................................................................95
ANNEXE - V - SCRIPTS AWK............................................................................................................98
ANNEXE - VI - EXTRAITS DU CODE SOURCE MODIFIE DE EIC......................................................99
86

Analyse dynamique de programmes C
87

Analyse dynamique de programmes C
Annexe - I -
Programmes de tests des interprètes C et traces de tests
TRACE D EXÉCUTION DE CINT AVEC L OPTION DE TRACE
POUR LE PROGRAMME DE CALCUL D UNE FACTORIELLE
--------------------------------------------
Programme de calcul d une factorielle : fact.c
1 /* fonction de calcul du factoriel d'un nombre => recurrence */
2 #include
3
4 unsigned int f, x;
5 unsigned int factoriel(unsigned int a);
6 int main(int argc, char *argv[])
7 {
8 puts("Entrez une valeur entière entre 1 et 8 :");
9 scanf("%d", &x);
10 if (x>8 || x

Analyse dynamique de programmes C
89

Analyse dynamique de programmes C
FICHIER MAIN DE LLISP
--------------------------------------------
1 /*
2 * main.c
3 */
4
5 #include "llisp/main.h"
6 #include "llisp/mem.c"
7 #include "llisp/print.c"
8 #include "llisp/std.c"
9 #include "llisp/read.c"
10 #include "llisp/eval.c"
11
12 extern int sp;
13 extern jmp_buf jmp_top;
14 extern jmp_buf jmp_file;
15 extern FILE *Stdin;
16 extern FILE *File;
17 extern void unbind();
18 extern void lisp_print();
19 extern void lisp_read();
20 extern void eval();
21 extern int int_read(char ch);
22 extern void obj_print(int obj);
23 extern void init_listes();
24
25 void toplevel()
26 {
27 for ( ;; )
28 {
29 printf ("? ");
30 fflush (stdout);
31 lisp_read();
32 eval();
33 printf ("= ");
34 lisp_print();
35 putchar ('\n');
36 fflush (stdout);
37 }
38 }
39
40 /* routine d'erreur : obj est un entier, adresse (index dans mem) d'un elt */
41 void err(char *fmt,int obj)
42 {
43 int i;
44 printf (fmt, obj);
45 while (sp > B_STACK)
46 if (pop(i) == -2)
47 unbind();
48 longjmp (jmp_top, 0);
49 }
50
51 void err2(char *fmt)
52 {
53 int i;
54 printf (fmt);
55 while (sp > B_STACK)
56 if (pop(i) == -2)
57 unbind();
58 longjmp (jmp_top, 0);
59 }
60
61 /* routine d'erreur : obj est une chaine (p_name) d'un elt */
62 void err_s(char *fmt,char *obj)
63 {
64 int i;
65 printf (fmt, obj);
66 while (sp > B_STACK)
90

Analyse dynamique de programmes C
67 if (pop(i) == -2)
68 unbind();
69 longjmp (jmp_top, 0);
70 }
71
72 void load (char *name)
73 {
74 if ((File = fopen (name, "r")) == NULL)
75 {
76 printf ("Le fichier %s n'existe pas\n", name);
77 }
78 else
79 {
80 printf ("Chargement de %s\n", name);
81 Stdin = File;
82 if (setjmp(jmp_file))
83 goto fini;
84 while (!feof(Stdin))
85 {
86 lisp_read();
87 eval();
88 lisp_print();
89 putchar ('\n');
90 }
91 fini:
92 fclose (File);
93 Stdin = stdin;
94 init_read();
95 }
96 }
97
98 void debug(char *s,int x)
99 {
100 printf("%s", s);
101 obj_print (x);
102 putchar ('\n');
103 }
104
105
106 int main()
107 {
108 static int nbtop = 0;
109 init_listes();
110 init_atomes();
111 setjmp (jmp_top);
112 init_read();
113 init_stack();
114 Stdin = stdin;
115 if (++nbtop == 1)
116 load ("llisp/llisp.ini");
117 toplevel();
118 return 0;
119 }
120
121 /* FIN de fichier */
122
91

Analyse dynamique de programmes C
Annexe - II -
Commandes internes à EiC en mode interactif
---------------------------------------------------------------------------
EiC-COMMAND
SUMMARY DESCRIPTION
---------------------------------------------------------------------------
:-I path
Append path to the include-file search list.
:-L
List search paths.
:-R path
Remove path from the include-file search list.
:clear fname
Removes the contents of file fname from EiC.
:exit
Terminates an EiC session.
:files
Display the names of all included files.
:files fname
Summarize the contents of the included file `fname'.
:gen fname
Generates EiC interface of the included file `fname'.
:gen fname [] Places the interface in outfile
:gen fname 4
Generates EiC interface with 4 levels of multiplexing.
:help
Display summary of EiC commands.
:history
List the history of all input commands.
:includes
Display path of include files when loaded.
:interpreter
Execute input commands. By default it is on.
:listcode
List stack code.
:listcode linenums
List stack code with associated line numbers.
:memdump
Show potential memory leaks.
:reset
Reset EiC back to its start state.
:reset here
Set the `reset' state to EiC's current state.
:rm dddd
Remove memory item dddd, which is a constant integer
value.
:rm f Removes f's definition from the symbol tables.
:show f
Shows type or macro definition of `f'.
:showline
Show input line after macro expansion.
:status
Display the status of the toggle switches.
:timer
Time in seconds of execution.
:trace
Trace function calls and line numbers during code
execution.
:trace funcs
Trace function calls only during code execution.
:variables
Display declared variables and interpreter-ed function
names.
:variables tags
Display the tag identifiers.
:variables type-name Display variables of type `type-name'.
:verbose
Suppresses EiC's copyright and warning messages on start
up.
-----------------------------------------------------------------------------------
92

Analyse dynamique de programmes C
93

Analyse dynamique de programmes C
Annexe - III -
Directiv es d appel à EiC en mode batch
To start eic, type eic.
To exit eic, type :exit.
Usage:
eic [-Ipath] [-Dname[=var]] -[hHvVcCrR] [[file] [fileargs]]
Options:
C preprocessor directives:
-Ipath
search for include files in path
-Dname define a symbolic name to the value 1
-Dname=var define a symbolic name to the value var
Note, there is no spaces allowed
EiC directives:
-h -H causes this usage to be displayed
-v V print EiC's Log information
-p showline
-P show path of include files
-t -T turns trace on
-c -C turns timer on
-e echo HTML mode
-r restart EiC. Causes EiC to be re initiated
from the contents of EiChist.lst file
-R same as `r', but prompts the user to accept
or reject each input line first
-s -S run silently
-f run in script mode
-n no history file
-N don't use any startup.h files
-A Non-interactive-mode
file
EiC will execute `file' and then stop; for example:
% eic foo.c
fileargs command line arguments, which get passed onto file
94

Analyse dynamique de programmes C
95

Analyse dynamique de programmes C
Annexe - IV -
Script shell "eic_adpc.sh
# eic_adpc.sh
# --------------------------------------------------------
# Fichier Shell qui lance l'execution de EiC en mode batch
# avec l'option de trace d'un programme.
#! /usr/bin/sh
RACINE="$HOME/bin"
PROGSC="$HOME/bin/codes_test"
DATA="$HOME/bin/datas"
DOT="$HOME/bin/dot"
GRAPH="$HOME/bin/graphs"
if [ -z "$1" ]
then
echo "Veuilez saisir un nom de fichier en argument."
exit 1
else
extension=`echo $1 | cut -f2 -d"."`
if [ "$extension" != c ]
then
echo "Le fichier n'est pas d'extension .c ! saisissez un nom valide de
fichier C."
else
if [ -r "$PROGSC/$1" ]
then
fichier=`echo $1 | cut -f1 -d "."`
./eic -t $PROGSC/$1 > $DATA/tmp.data
awk -f $RACINE/formaterdata.awk $DATA/tmp.data >
$DATA/$fichier.data
awk -f $RACINE/graph1.awk $DATA/$fichier.data >
$DOT/$fichier.dot
awk -f $RACINE/graph2.awk $DATA/$fichier.data >>
$DOT/$fichier.dot
dot -Tps -o $GRAPH/$fichier.ps $DOT/$fichier.dot
gv $GRAPH/$fichier.ps
else
echo "Le fichier n'existe pas ou n'est pas en droit de lecture."
fi
fi
fi
96

Analyse dynamique de programmes C
97

Analyse dynamique de programmes C
Annexe - V - Scripts awk
# formaterdata.awk
# --------------------------------------------------------
# Supprime la base de donnee pour ne garder que les données
# du programme a analyser
/codes_test\//,/EiC/ { print $0 }
# graph1.awk
# --------------------------------------------------------
# Genere les premieres lignes du fichier .dot
BEGIN { printf "digraph G { ranksep=.75; size=\"7.5,7.5\";\n{\nnode
[shape=plaintext, fontsize=16];\n" }
# { print }
$1 == "#" { printf "\"%s\" -> ", $2 }
END { printf "\"end\";\n}\n" }
# graph2.awk
# --------------------------------------------------------
# Genere l essentiel du fichier .dot
BEGIN { lastline = " " }
$1 == "main" { printf "{rank = same;\n\"%s:%s\"; \"#%s:%s\";\n}\n\n", $2, $3, $2,
$3
printf "\"#%s:%s\" [label=\"main-%s\", shape=box, color=red]\n", $2,
$3, $3
#printf "\"#%s:%s\" -> ", $2, $3
lastline = "\"#"$2":"$3"\""}
$1 == "Def" { if (lastline != " ") { printf "%s -> \"#%s:%s\"\n\n", lastline, $4,
$5
lastline = " " }
$3 }
printf "{rank = same;\n\"%s:%s\"; \"#%s:%s\";\n}\n", $4, $5, $4, $5
printf "\"#%s:%s\" [label=\"%s=%s\", color=green]\n\n", $4, $5, $2,
$1 == "Use" { printf "\"#%s:%s\" -> \"#%s:%s\"\n", $3, $4, $5, $6 }
$1 == "Call" { i = 4
if (lastline != " ") { printf "%s -> \"#%s:%s\"\n\n", lastline, $2, $3
lastline = "\"#"$2":"$3"\"" }
#printf "\"#%s:%s\"\n", $2, $3
printf "{rank = same;\n\"%s:%s\"; \"#%s:%s\";\n}\n", $2, $3, $2, $3
printf "\"#%s:%s\" [label=\"Call-%s\\n", $2, $3, $3
while (i \"#%s:%s\"\n\n", lastline, $4,
$5
lastline = "\"#"$4":"$5"\"" }
#printf "\"#%s:%s\"\n", $4, $5
98

Analyse dynamique de programmes C
printf "{rank = same;\n\"%s:%s\"; \"#%s:%s\";\n}\n", $4, $5, $4, $5
printf "\"#%s:%s\" [label=\"Cond-%s\\n%s\", shape=diamond, headport=w,
tailport=e]\n", $4, $5, $5, $2
if ($3 == "0") lastline="\"#"$4":"$5"\":e"
else lastline="\"#"$4":"$5"\":w" }
$1 == "Return" { if (lastline != " ") { printf "%s -> \"#%s:%s\"\n\n", lastline, $3,
$4
lastline = "\"#"$3":"$4"\"" }
#printf "\"#%s:%s\"\n", $3, $4
printf "{rank = same;\n\"%s:%s\"; \"#%s:%s\";\n}\n", $3, $4, $3, $4
printf "\"#%s:%s\" [label=\"Return-%s\\n%s\", shape=box]\n", $3, $4,
$4, $2 }
END { printf "\n}\n" }
99

Analyse dynamique de programmes C
Annexe - VI - Extraits du code source modifié de EiC
1 /* interpre.c
2 *
3 * (C) Copyright Apr 15 1995, Edmond J. Breen.
4 * ALL RIGHTS RESERVED.
5 * This code may be copied for personal, non-profit use only.
6 *
7 */
8
9 #include
10 #include
11 #include
12 #include
13 #include
14 #include
15 #include
16
17 #include "MachSet.h"
18 #include "global.h"
19 #include "xalloc.h"
20 #include "lexer.h"
21 #include "typemod.h"
22 #include "symbol.h"
23 #include "func.h"
24 #include "typesets.h"
25 #include "preproc.h"
26 #include "cdecl.h"
27 #include "emitter.h"
28
29 #include "error.h"
30
31 /* make a safe memory block */
32 #define MASSIGN \
33
34 #define checkPtr(P,s,i) \
35 if(( (char *)P.p + i ) > (char *) P.ep || P.p < P.sp) {\
36 if(( (char *)P.p + i ) > (char *) P.ep) {\
37 EiC_messageDisplay(s ": attempted beyond allowed access area\n"); }\
38 else\
39 EiC_messageDisplay(s ": attempted before allowed access area\n");\
40 raise(SIGSEGV);\
41 }
42
43
44 #define FMEM xfree(AR[InSt[p].ext][InSt[p].val.ival].v.p.sp)
45
46 #define LDA
47
48 #define LVAL
49
50 #define stoTYPE(x) AR[InSt[p].ext][InSt[p].val.ival].v.x = STK[ToP].v.x;
51 /*printf("STK[ToP].v.sym->id = %s\n",STK[ToP].v.sym->id);*/
52
53 #define stoVAL env->LAR[env->lsp].v = STK[ToP].v;\
54 /*printf(" -%d- ",env->LAR[env->lsp].v.ival);*/ \
55 env->lsp++;
56
57 #define pushVAL _ STK[ToP].v = InSt[p].val;
58 #define assignTYPE_ env->LAR[env->lsp-1].type = InSt[p].val.p.p
59
60 #define rvalTYPE(x) STK[ToP].v.x = AR[InSt[p].ext][InSt[p].val.ival].v.x
61
62 #define drefTYPE(x,y) checkPtr(STK[ToP].v.p,"READ", sizeof(x) );\
100

Analyse dynamique de programmes C
63 STK[ToP].v.y = *(x*)STK[ToP].v.p.p
64
65 #define refTYPE(x,y) ToP--;\
66 checkPtr(STK[ToP].v.p,"WRITE", sizeof(x) );\
67 *(x*)STK[ToP].v.p.p = STK[ToP+1].v.y;\
68 STK[ToP].v.y = STK[ToP+1].v.y
69
70 #define refMEM ToP--;\
71 memcpy(STK[ToP].v.p.p,STK[ToP+1].v.p.p,InSt[p].val.ival);\
72 STK[ToP].v.p.sp = STK[ToP].v.p.p;\
73 STK[ToP].v.p.ep = (char*)STK[ToP].v.p.p + InSt[p].val.ival;
74
75 #define pushTYPE(x) STK[ToP].v.x = InSt[p].val.x;\
76 /*printf("STK[%d].v.ival = %d\n",ToP,STK[ToP].v.ival);*/
77
78 #define castTYPES(x,y,T) STK[ToP].v.y = (T)STK[ToP].v.x
79
80 #define negTYPE(x) STK[ToP].v.x = -STK[ToP].v.x
81 #define addTYPE(x) ToP--; STK[ToP].v.x += STK[ToP+1].v.x
82 #define subTYPE(x) ToP--; STK[ToP].v.x -= STK[ToP+1].v.x
83 #define divTYPE(x) ToP--; STK[ToP].v.x /= STK[ToP+1].v.x
84 #define multTYPE(x) ToP--; STK[ToP].v.x *= STK[ToP+1].v.x
85 #define modTYPE(x) ToP--; STK[ToP].v.x %= STK[ToP+1].v.x
86 #define lshtTYPE(x) ToP--; STK[ToP].v.x = STK[ToP+1].v.x
88 #define ltTYPE(x) ToP--; STK[ToP].v.ival = STK[ToP].v.x < STK[ToP+1].v.x;\
89 if(EiC_traceON) {\
90 cond = STK[ToP].v.ival; \
91 printf("\tCond (%d

Analyse dynamique de programmes C
131 extern int EiC_traceON;
132 extern int EiC_traceFunc;
133 extern int EiC_interActive;
134
135
136 #define stacksize 200
137 typedef AR_t STK_t;
138
139 STK_t *AR[3];
140 size_t ARGC;
141
142 val_t EiC_STaCK_VaLuE;
143
144 void EiC_interpret(environ_t * env)
145 {
146 int p,Jmpu,cond,i;
147 /* Jmpu --> indicateur de boucle 1 si dans boucle et 0 sinon */
148 /*int k;
149 symentry_t *sym;
150 */
151 static int cpti;
152 size_t argc;
153 unsigned int ToP;
154 InsT_t *InSt;
155 STK_t *STK, *hold_AR, *hold_AR1;
156
157 /* EXPLANATION OF REGISTERS
158 * ToP stack top;
159 * p program counter;
160 * InSt pointer to instruction set
161 */
162
163 typedef struct {
164 int p;
165 unsigned int top;
166 int lsp;
167 long offset;
168 void *file;
169 void *inst;
170 void *ar;
171 } _EiC_jmp_buf;
172
173
174 /* Ajout par Rim Chaabane rchaabane@free.fr (02/2005 -> 09/2005)
175 Structure qui pour chaque instruction identifiée par num_i,
176 permet de compter so nombre d'appels cptr_a, cette structure
177 permet également d'enregistrer le numéro de la dernière
178 instruction ou la variable est appelée & le nombre d'appels
179 a cette derniere
180
181 */
182 typedef struct {
183 int num_i; /* numero d'instruction */
184 unsigned int cptr_a; /* compteur d'appels d'instructions */
185 int dernier_appel; /* enregistre l'id de la dernière ligne
d'instruction ou est appelée la var */
186 int dernier_pass; /* enregistre le num de passage de l'instruction ou
est appelée la var */
187 } inf_inst;
188
189 extern int EiC_TIMER;
190 extern void EiC_showvalue(AR_t *);
191 extern symentry_t * EiC_lookup(char nspace, char *id);
192
193 int stksz = stacksize;
194 int lastln = -1;
195 eicstack_t names = {0, NULL};
196 val_t v;
102

Analyse dynamique de programmes C
197 void *vp; /* for temporay use only */
198
199 #define N 50
200 inf_inst T[N];
201 /* Initialisation a 0 de la valeur de cptr_a et le numero d instruction */
202 for (i=0; iAR;
215 AR[1] = &env->LAR[env->lsp];
216 InSt = env->CODE.inst;
217 ToP = 0;
218 p = 0;
219
220 STK[ToP].v.dval = 0;
221 ON = 1;
222
223 start = clock();
224 EiC_CurrentFile = codeName(&env->CODE);
225 /*Jmpu = 0;*/
226
227 _while (ON) {
228 _/* renvoi tjs le nom du fichier pr var.c_
229 for(k=0;kstab.n;++k) {
230 _ _printf("stab->strs[%d]=%s\n",k,env->stab.strs[k]);
231 _}
232 _*/
233 _if(EiC_CurrentLine != InSt[p].line) /* for error reporting */
234 EiC_CurrentLine = InSt[p].line; /* purposes only */
235 if(EiC_traceON) {
236
237 if(InSt[p].opcode == eiccall) {
238 EiC_eicpush(&names,v);
239 v.p.p = ((symentry_t *) STK[ToP - 1].v.p.p)->id;
240 lastln = InSt[p].line;
241 }
242 if(!EiC_traceFunc && lastln != InSt[p].line && InSt[p].line) {
243 lastln = InSt[p].line;
244 cpti++;
245 T[lastln].cptr_a ++;
246 _printf("\n# %d:%d
\n",lastln,T[lastln].cptr_a,(char*)EiC_CurrentFile);
247 _if (T[lastln].num_i == 0) T[lastln].num_i = cpti; _
248 }
249
250 }
251
252 switch (InSt[p].opcode) {
253 case bump:
254 /*if(EiC_traceON) printf("pump\n");*/
255 AdjustTop(InSt[p].val.ival);
256 ToP += InSt[p].val.ival;
257 break;
258 case jmpFint:
259 jmpfTYPE(ival); if(EiC_traceON) printf("jmpftype ival \n");
260 break;
261 case jmpFlng:
262 jmpfTYPE(lval); if(EiC_traceON) printf("jmpftype lval\n");
263 break;
103

Analyse dynamique de programmes C
264 case jmpFdbl:
265 jmpfTYPE(dval); if(EiC_traceON) printf("jmpftype dval\n");
266 break;
267 case jmpFptr:
268 jmpfTYPE(p.p); if(EiC_traceON) {printf("jmpftype p.p\n");}
269 break;
270 case jmpFllng:
271 jmpfTYPE(llval); /*if(EiC_traceON) {printf("jmpftype
llval"); }*/
272 break;
273
274 case jmpTint:
275 jmptTYPE(ival); /*if(EiC_traceON) {printf("jmptTint "); }*/
276 break;
277 case jmpTlng:
278 jmptTYPE(lval); /*if(EiC_traceON) {printf("jmpTlng "); }*/
279 break;
280 case jmpTdbl:
281 jmptTYPE(dval);/* if(EiC_traceON) {printf("jmpTdbl "); }*/
282 break;
283 case jmpTptr:
284 jmptTYPE(p.p);/*if(EiC_traceON) { printf("jmpTptr "); }*/
285 break;
286 case jmpTllng:
287 jmptTYPE(llval); /*if(EiC_traceON) {printf("jmpTllng "); }*/
288 break;
289
290 case jmpu: p += InSt[p].val.ival - 1;
291 /*if(EiC_traceON) { printf("jmpu \n"); }*/
292 break;
293 case dupval:
294 /* should really adjustTop here !!*/
295 STK[ToP + 1].v = STK[ToP].v;
296 ToP += InSt[p].val.ival;
297 /*if(EiC_traceON) {printf("dupval "); }*/
298 break;
299 case jmptab:
300 {
301 /*if(EiC_traceON) {printf("jmptab "); }*/
302 struct {
303 int n;
304 val_t *loc;
305 } *tab;
306 int i;
307 tab = InSt[p].val.p.p;
308 for (i = 1; i < tab->n; i += 2)
309 if (tab->loc[i].ival == STK[ToP].v.ival) {
310 p += tab->loc[i + 1].ival - 1;
311 break;
312 }
313 if (i >= tab->n)
314 p += tab->loc[0].ival - 1;
315 }
316 break;
317
318
319 /* specific float stuff */
320
321 case dreffloat:
322 drefTYPE(float, dval); /*if(EiC_traceON) { printf("dreffloat
");}*/
323 break;
324 case reffloat: refTYPE(float, dval);/* if(EiC_traceON)
{printf("reffloat ");} */
325 break;
326 case rvalfloat:
327 STK[ToP].v.dval=AR[InSt[p].ext][InSt[p].val.ival].v.fval;
/*if(EiC_traceON) { printf("rvalfloat ");}*/
104

Analyse dynamique de programmes C
328 break;
329 case stofloat:
330 AR[InSt[p].ext][InSt[p].val.ival].v.fval =
(float)STK[ToP].v.dval; /*if(EiC_traceON) {printf("stofloat ");}*/
331 break;
332
333
334 /* specific short stuff */
335 case rvalshort:
336 STK[ToP].v.ival=AR[InSt[p].ext][InSt[p].val.ival].v.sval;
/*if(EiC_traceON) {printf("rvalshort ");}*/
337 break;
338 case rvalushort:
339 STK[ToP].v.ival=AR[InSt[p].ext][InSt[p].val.ival].v.usval;/*
if(EiC_traceON) { printf("rvalushort ");}*/
340 break;
341 case drefushort:
342 drefTYPE(unsigned short, ival);/*if(EiC_traceON)
{ printf("drefushort ");}*/
343 break;
344 case drefshort:
345 drefTYPE(short, ival);/* if(EiC_traceON) {printf("drefshort
");}*/
346 break;
347 case refshort: refTYPE(short, ival); /*if(EiC_traceON)
{printf("refshort ");} */
348 break;
349 case stoshort:
350 AR[InSt[p].ext][InSt[p].val.ival].v.sval = STK[ToP].v.ival;
351 /*if(EiC_traceON) {printf("stoshort ");}*/
352 break;
353
354 /* specific char stuff */
355 case rvalchar:
356 STK[ToP].v.ival=AR[InSt[p].ext][InSt[p].val.ival].v.cval;
357 /*if(EiC_traceON) {printf("rvalchar "); }*/
358 break;
359 case rvaluchar:
360 STK[ToP].v.ival=AR[InSt[p].ext][InSt[p].val.ival].v.ucval;
361 /*if(EiC_traceON) {printf("rvaluchar "); }*/
362 break;
363 case stochar:
364 AR[InSt[p].ext][InSt[p].val.ival].v.cval = STK[ToP].v.ival;
365 /*if(EiC_traceON) {printf("stochar ");}*/
366 break;
367 case drefuchar:
368 drefTYPE(unsigned char, ival); /*if(EiC_traceON)
{printf("drefuchar "); }*/
369 break;
370 case drefchar:
371 drefTYPE(char, ival); /*if(EiC_traceON) {printf("drefchar
"); }*/
372 break;
373 case refchar: refTYPE(char, ival); /*if(EiC_traceON)
{printf("refchar "); }*/
374 break;
375 case neguchar: STK[ToP].v.uival = 256 - STK[ToP].v.uival;
/*if(EiC_traceON) {printf("neguchar "); }*/
376 break;
377
378 /* specific int stuff */
379 case incint: STK[ToP].v.ival += InSt[p].val.ival; /*if(EiC_traceON)
{printf("incrint ");}*/
380 break;
381 case decint: STK[ToP].v.ival -= InSt[p].val.ival;/*if(EiC_traceON)
{ printf("decrint"); }*/
382 break;
383 case drefint:
105

Analyse dynamique de programmes C
384 drefTYPE(int, ival); /*if(EiC_traceON) {printf("drefint ");} */
385 break;
386 case refint: refTYPE(int, ival);/*if(EiC_traceON) { printf("refint
"); }*/
387 break;
388 case stoint: stoTYPE(ival);
389 if(EiC_traceON) {
390 /*printf("\nstoint \n");*/
391 AR[InSt[p].ext][InSt[p].val.ival].line = InSt[p].line;
392 printf("\tDef %d-%d %d %d %d\n",
393 InSt[p].ext,
394 InSt[p].val.ival,
395 /*((symentry_t *)AR[0][InSt[p].val.ival].v.sym)->id,*/
396 /*((symentry_t *)AR[InSt[p].ext][InSt[p].val.ival].v.p.p)-
>id,*/
397 /*token->Val.sym->id,*/
398 /*(char *) AR[InSt[p].ext][InSt[p].val.ival].v.sym->id,*/
399 /*InSt.val.sym->id,*/
400 /*token->Val.sym->id,*/
401 /*((symentry_t *) STK[ToP - 1].v.p.p)->id,*/
402 AR[InSt[p].ext][InSt[p].val.ival].v.ival,
403 InSt[p].line,
404 T[InSt[p].line].cptr_a
405 ); /* id_symbole, valeur, id_intruction(num_instr-nb_appels)
*/
406
407 /*
408 for (k = 0; k < HSIZE; k++)
409 for (sym = EiC_HTAB[k]; sym!= NULL; sym = sym->next) {
410 printf("- k = %d - ",k);
411 fputs(sym->id, stdout);
412 fputc('\n', stdout);
413 }
414 */
415
416 T[InSt[p].line].dernier_appel=
InSt[p].line;/*[InSt[p].line].num_i;*/
417 T[InSt[p].line].dernier_pass= T[lastln].cptr_a;_
418 }
419
420 break;
421 case rvalint: rvalTYPE(ival);
422 if(EiC_traceON) {
423 /*printf("\n rvalint \n");*/
424 printf("\tUse %d-%d %d %d %d %d \n",
425 InSt[p].ext,
426 InSt[p].val.ival,
427 /*((symentry_t *)AR[InSt[p].ext][InSt[p].val.ival].v.sym)-
>id,*/
428 T[AR[InSt[p].ext][InSt[p].val.ival].line].dernier_appel,
429 T[AR[InSt[p].ext][InSt[p].val.ival].line].dernier_pass,
430 InSt[p].line,
431 T[InSt[p].line].cptr_a
432 );/*id_symbole, appel de, id_instruction(num_instrnb_appels)*/
433 }
434 break;
435 case pushint: pushTYPE(ival); /*if(EiC_traceON) {printf("pushint
");}*/
436 break;
437 case negint: negTYPE(ival); /*if(EiC_traceON) {printf("negtype -
\n");} */
438 break;
439 case addint: addTYPE(ival); /*if(EiC_traceON) {printf("\t
\"+\"\n");} */
440 break;
441 case subint: subTYPE(ival); /*if(EiC_traceON) {printf("\t \"-
\"\n");} */
106

Analyse dynamique de programmes C
442 break;
443 case divint: divTYPE(ival); /*if(EiC_traceON) {printf("divint
\n");} */
444 break;
445 case multint: multTYPE(ival); /*if(EiC_traceON) {printf("multint
\n");} */
446 break;
447 case modint: modTYPE(ival); /*if(EiC_traceON) {printf("modint
\n");} */
448 break;
449 case lshtint: lshtTYPE(ival); /*if(EiC_traceON) {printf("lshtint
\n");} */
450 break;
451 case rshtint: rshtTYPE(ival); /*if(EiC_traceON) {printf("rshtint
\n");} */
452 break;
453 case ltint: ltTYPE(ival);
454 if(EiC_traceON) {
455 printf("%d %d\n",InSt[p].line,T[InSt[p].line].cptr_a);
456 /*
457 if (STK[ToP].v.ival==1 && cpt_psgBoucle==0) cpt_psgBoucle++;
458 if (STK[ToP].v.ival==1 && cpt_psgBoucle!=0) cpt_psgBoucle++;
459 if (STK[ToP].v.ival==0) { cpt_psgBoucle=0; Jmpu--; }
460 */
461 }
462 break;
463 case leint: leTYPE(ival); /*if(EiC_traceON) {printf("\t
\"\"\n"); }*/
470 break;
471 case geint: geTYPE(ival); /*if(EiC_traceON) {printf("\t
\">=\"\n"); }*/
472 break;
473 case lorint: lorTYPE(ival);/* if(EiC_traceON) {printf("\t
\"||\"\n");} */
474 break;
475 case landint: landTYPE(ival);/* if(EiC_traceON) {printf("\t
\"!=0\"\n"); }*/
476 break;
477 case notint: notTYPE(ival); /*if(EiC_traceON) {printf("notint
\n"); }*/
478 break;
479 case borint: borTYPE(ival); /*if(EiC_traceON) {printf("borint
\n"); }*/
480 break;
481 case xorint: xorTYPE(ival); /*if(EiC_traceON) {printf("xorint
\n"); }*/
482 break;
483 case andint: andTYPE(ival); /*if(EiC_traceON) {printf("andint
\n"); }*/
484 break;
485 case compint: compTYPE(ival); /*if(EiC_traceON) {printf("compint
\n");} */
486 break;
487 case int2double: castTYPES(ival, dval, double); /*if(EiC_traceON)
{ printf("int2double ");}*/
488 break;
489 case int2ptr: castTYPES(ival, p.p, void *); /*if(EiC_traceON)
{printf("int2ptr ");}*/
490 break;
107

Analyse dynamique de programmes C
491 case int2long: castTYPES(ival, lval, long); /* if(EiC_traceON)
{printf("int2long ");}*/
492 break;
493 case int2llong: castTYPES(ival, llval, eic_llong);
/*if(EiC_traceON) { printf("int2llong ");}*/
494 break;
495 case int2uchar: castTYPES(ival, lval, unsigned char);
/*if(EiC_traceON) { printf("int2uchar ");}*/
496 break;
497 case int2ushort: castTYPES(ival, lval, unsigned short);
/*if(EiC_traceON) {printf("int2ushort ");}*/
498 break;
499
500 /* unsigned int stuff */
501 case incuint: STK[ToP].v.uival += InSt[p].val.uival;
/*if(EiC_traceON) { printf("incuint ");}*/
502 break;
503 case decuint: STK[ToP].v.uival -= InSt[p].val.uival;
/*if(EiC_traceON) { printf("decuint ");}*/
504 break;
505 case drefuint:
506 drefTYPE(unsigned, uival); /*if(EiC_traceON) { printf("drefuint
");}*/
507 break;
508 case refuint: refTYPE(unsigned, uival); /*if(EiC_traceON)
{ printf("refuint ");}*/
509 break;
510 case stouint: stoTYPE(uival); /*if(EiC_traceON) { printf("stouint
");}*/
511 break;
512 case rvaluint: rvalTYPE(uival); /*if(EiC_traceON)
{ printf("rvaluint ");}*/
513 break;
514 case pushuint: pushTYPE(uival); /*if(EiC_traceON)
{ printf("pushuint ");}*/
515 break;
516 case neguint: negTYPE(uival); /*if(EiC_traceON) { printf("neguint
");}*/
517 break;
518 case adduint: addTYPE(uival);/* if(EiC_traceON) { printf("adduint
");}*/
519 break;
520 case subuint: subTYPE(uival); /*if(EiC_traceON) { printf("subuint
");}*/
521 break;
522 case divuint: divTYPE(uival); /*if(EiC_traceON) { printf("divuint
");}*/
523 break;
524 case multuint: multTYPE(uival); /*if(EiC_traceON)
{ printf("multuint ");}*/
525 break;
526 case moduint: modTYPE(uival); /*if(EiC_traceON) { printf("moduint
");}*/
527 break;
528 case lshtuint: lshtTYPE(uival);/* if(EiC_traceON)
{ printf("lshuint ");}*/
529 break;
530 case rshtuint: rshtTYPE(uival); /*if(EiC_traceON)
{ printf("rshtuint ");}*/
531 break;
532 case ltuint: ltTYPE(uival); /*if(EiC_traceON) {printf("ltuint
");}*/
533 break;
534 case leuint: leTYPE(uival); /*if(EiC_traceON) { printf("leuint
");}*/
535 break;
536 case equint: eqTYPE(uival); /*if(EiC_traceON) { printf("equint
");}*/
108

Analyse dynamique de programmes C
537 break;
538 case neuint: neTYPE(uival); /*if(EiC_traceON) { printf("neuint
");}*/
539 break;
540 case gtuint: gtTYPE(uival); /*if(EiC_traceON) { printf("gtuint
");}*/
541 break;
542 case geuint: geTYPE(uival); /*if(EiC_traceON) {printf("geuint
");}*/
543 break;
544 case loruint: lorTYPE(uival);/* if(EiC_traceON) { printf("loruint
");}*/
545 break;
546
547 case notuint: notTYPE(uival); /*if(EiC_traceON)
{ printf("notuint");}*/
548 break;
549 case boruint: borTYPE(uival); /*if(EiC_traceON)
{printf("boruint"); }*/
550 break;
551 case xoruint: xorTYPE(uival); /*if(EiC_traceON) { printf("xoruint
"); }*/
552 break;
553 case anduint: andTYPE(uival); /*if(EiC_traceON) { printf("anduint
"); }*/
554 break;
555 case compuint: compTYPE(uival); /*if(EiC_traceON)
{printf("compuint ");} */
556 break;
557 case uint2double: castTYPES(uival, dval, double); /*if(EiC_traceON)
{printf("uint2double "); }*/
558 break;
559 case uint2ptr: castTYPES(uival, p.p, void *); /*if(EiC_traceON)
{printf("uint2ptr "); }*/
560 break;
561 case uint2long: castTYPES(uival, lval, long); /*if(EiC_traceON)
{printf("uint2long "); }*/
562 break;
563 case uint2llong: castTYPES(uival, llval, eic_llong);/*
if(EiC_traceON) {printf("uint2llong "); }*/
564 break;
565
566 /* specific long stuff */
567 case inclong: STK[ToP].v.lval += InSt[p].val.ival;
568 break;
569 case declong: STK[ToP].v.lval -= InSt[p].val.ival;
570 break;
571 case dreflong:
572 drefTYPE(long, lval);
573 break;
574 case reflong: refTYPE(long, lval);
575 break;
576 case stolong: stoTYPE(lval);
577 break;
578 case rvallong: rvalTYPE(lval);
579 break;
580 case pushlong: pushTYPE(lval);
581 break;
582 case neglong: negTYPE(lval);
583 break;
584 case addlong: addTYPE(lval);
585 break;
586 case sublong: subTYPE(lval);
587 break;
588 case divlong: divTYPE(lval);
589 break;
590 case multlong: multTYPE(lval);
591 break;
109

Analyse dynamique de programmes C
592 case modlong: modTYPE(lval);
593 break;
594 case lshtlong: lshtTYPE(lval);
595 break;
596 case rshtlong: rshtTYPE(lval);
597 break;
598 case ltlong: ltTYPE(lval);
599 break;
600 case lelong: leTYPE(lval);
601 break;
602 case eqlong: eqTYPE(lval);
603 break;
604 case nelong: neTYPE(lval);
605 break;
606 case gtlong: gtTYPE(lval);
607 break;
608 case gelong: geTYPE(lval);
609 break;
610 case lorlong: lorTYPE(lval);
611 break;
612 case landlong: landTYPE(lval);
613 break;
614 case notlong: notTYPE(lval);
615 break;
616 case borlong: borTYPE(lval);
617 break;
618 case xorlong: xorTYPE(lval);
619 break;
620 case andlong: andTYPE(lval);
621 break;
622 case complong: compTYPE(lval);
623 break;
624 case long2double: castTYPES(lval, dval, double);
625 break;
626 case long2ptr: castTYPES(lval, p.p, void *);
627 break;
628 case long2llong: castTYPES(lval, llval, eic_llong);
629 break;
630 case long2int: castTYPES(lval, ival, int);
631 break;
632
633 /* unsigned long stuff */
634 case inculong: STK[ToP].v.ulval += InSt[p].val.ival;
635 break;
636 case deculong: STK[ToP].v.ulval -= InSt[p].val.ival;
637 break;
638 case drefulong:
639 drefTYPE(unsigned long, ulval);
640 break;
641 case refulong: refTYPE(unsigned long, ulval);
642 break;
643 case stoulong: stoTYPE(ulval);
644 break;
645 case rvalulong: rvalTYPE(ulval);
646 break;
647 case pushulong: pushTYPE(ulval);
648 break;
649 case negulong: negTYPE(ulval);
650 break;
651 case addulong: addTYPE(ulval);
652 break;
653 case subulong: subTYPE(ulval);
654 break;
655 case divulong: divTYPE(ulval);
656 break;
657 case multulong: multTYPE(ulval);
658 break;
659 case modulong: modTYPE(ulval);
110

Analyse dynamique de programmes C
660 break;
661 case lshtulong: lshtTYPE(ulval);
662 break;
663 case rshtulong: rshtTYPE(ulval);
664 break;
665 case ltulong: ltTYPE(ulval);
666 break;
667 case leulong: leTYPE(ulval);
668 break;
669 case equlong: eqTYPE(ulval);
670 break;
671 case neulong: neTYPE(ulval);
672 break;
673 case gtulong: gtTYPE(ulval);
674 break;
675 case geulong: geTYPE(ulval);
676 break;
677 case lorulong: lorTYPE(ulval);
678 break;
679
680 case notulong: notTYPE(ulval);
681 break;
682 case borulong: borTYPE(ulval);
683 break;
684 case xorulong: xorTYPE(ulval);
685 break;
686 case andulong: andTYPE(ulval);
687 break;
688 case compulong: compTYPE(ulval);
689 break;
690 case ulong2double: castTYPES(ulval, dval, double);
691 break;
692 case ulong2ptr: castTYPES(ulval, p.p, void *);
693 break;
694 case ulong2int: castTYPES(ulval, ival, int);
695 break;
696 case ulong2llong: castTYPES(ulval, llval, eic_llong);
697 break;
698
699
700
701 /* specific long long stuff */
702 case incllong: STK[ToP].v.llval += InSt[p].val.ival;
703 break;
704 case decllong: STK[ToP].v.llval -= InSt[p].val.ival;
705 break;
706 case drefllong:
707 drefTYPE(eic_llong, llval);
708 break;
709 case refllong: refTYPE(eic_llong, llval);
710 break;
711 case stollong: stoTYPE(llval);
712 break;
713 case rvalllong: rvalTYPE(llval);
714 break;
715 case pushllong: pushTYPE(llval);
716 break;
717 case negllong: negTYPE(llval);
718 break;
719 case addllong: addTYPE(llval);
720 break;
721 case subllong: subTYPE(llval);
722 break;
723 case divllong: divTYPE(llval);
724 break;
725 case multllong: multTYPE(llval);
726 break;
727 case modllong: modTYPE(llval);
111

Analyse dynamique de programmes C
728 break;
729 case lshtllong: lshtTYPE(llval);
730 break;
731 case rshtllong: rshtTYPE(llval);
732 break;
733 case ltllong: ltTYPE(llval);
734 break;
735 case lellong: leTYPE(llval);
736 break;
737 case eqllong: eqTYPE(llval);
738 break;
739 case nellong: neTYPE(llval);
740 break;
741 case gtllong: gtTYPE(llval);
742 break;
743 case gellong: geTYPE(llval);
744 break;
745 case lorllong: lorTYPE(llval);
746 break;
747 case landllong: landTYPE(llval);
748 break;
749 case notllong: notTYPE(llval);
750 break;
751 case borllong: borTYPE(llval);
752 break;
753 case xorllong: xorTYPE(llval);
754 break;
755 case andllong: andTYPE(llval);
756 break;
757 case compllong: compTYPE(llval);
758 break;
759 case llong2double: castTYPES(llval, dval, double);
760 break;
761 case llong2ptr: castTYPES(llval, p.p, void *);
762 break;
763 case llong2int: castTYPES(llval, ival, int);
764 break;
765 case llong2long: castTYPES(llval, lval, long);
766 break;
767
768
769 /* specific double stuff */
770 case incdouble:STK[ToP].v.dval += InSt[p].val.ival;
771 break;
772 case decdouble:STK[ToP].v.dval -= InSt[p].val.ival;
773 break;
774 case drefdouble:
775 drefTYPE(double, dval);
776 break;
777 case refdouble: refTYPE(double, dval);
778 break;
779 case stodouble: stoTYPE(dval);
780 break;
781 case rvaldouble: rvalTYPE(dval);
782 break;
783 case pushdouble: pushTYPE(dval);
784 break;
785 case negdouble: negTYPE(dval);
786 break;
787 case adddouble: addTYPE(dval);
788 break;
789 case subdouble: subTYPE(dval);
790 break;
791 case divdouble: divTYPE(dval);
792 break;
793 case multdouble: multTYPE(dval);
794 break;
795 case ltdouble: ltTYPE(dval);
112

Analyse dynamique de programmes C
796 break;
797 case ledouble: leTYPE(dval);
798 break;
799 case eqdouble: eqTYPE(dval);
800 break;
801 case nedouble: neTYPE(dval);
802 break;
803 case gtdouble: gtTYPE(dval);
804 break;
805 case gedouble: geTYPE(dval);
806 break;
807 case lordouble: lorTYPE(dval);
808 break;
809 case landdouble: landTYPE(dval);
810 break;
811 case notdouble: notTYPE(dval);
812 break;
813
814 case double2int: castTYPES(dval, uival, unsigned int);
815 break;
816 case double2long: castTYPES(dval, ulval, unsigned long);
817 break;
818 case double2llong: castTYPES(dval, llval, eic_llong);
819 break;
820 case double2float: castTYPES(dval, fval, float);
821 break;
822
823
824 /*specific pointer stuff */
825 case incptr: STK[ToP].v.p.p = (char *) STK[ToP].v.p.p +
826 InSt[p].val.ival; /*if(EiC_traceON) {printf("incptr "); }*/
827 break;
828 case decptr: STK[ToP].v.p.p = (char *) STK[ToP].v.p.p -
829 InSt[p].val.ival; /*if(EiC_traceON) {printf("decptr "); }*/
830 break;
831 case lda:
832 #if 0
833 STK[ToP].v.p = AR[1][InSt[p].val.ival].v.p;
834 STK[ToP].v.p.p = (char*)STK[ToP].v.p.sp + InSt[p].ext;
835 STK[ToP].v.p.sp = STK[ToP].v.p.p;
836 if(EiC_traceON) {printf("lda if 0\n"); }
837 #else
838
839 {
840 if(EiC_traceON) {printf("lda if non 0\n"); }
841 ptr_t *q = &AR[1][InSt[p].val.ival].v.p;
842 ptr_t *a = &STK[ToP].v.p;
843
844 a->p = a->sp = (char*)q->sp + InSt[p].ext;
845 a->ep = q->ep;
846
847 if(vp) { /* patch previous lda assignment */
848 ((ptr_t*)vp)->ep = (char*)a->p;
849 }
850 /* Take advantage of the fact that the next InSt
851 * has the location of where `a' is to be stored.
852 */
853 vp = &AR[1][InSt[p+1].val.ival].v.p;
854
855 }
856
857 #endif
858
859 break;
860 case ixa:
861 ToP--;
862 STK[ToP].v.p.p = (char *) STK[ToP].v.p.p +
STK[ToP+1].v.ival*InSt[p].val.ival;
113

Analyse dynamique de programmes C
863 if(EiC_traceON) {printf("ixa \n"); }
864 break;
865 case addptr2int: ToP--;
866 STK[ToP].v.p.p = (char *) STK[ToP].v.p.p + STK[ToP + 1].v.ival;
if(EiC_traceON) {printf("add2ptrint "); }
867 break;
868 case addint2ptr: ToP--;
869 STK[ToP].v.p.p = STK[ToP].v.ival
870 + (char *) STK[ToP+1].v.p.p; if(EiC_traceON)
{printf("addint2ptr\n"); }
871 break;
872 case subptrint: ToP--;
873 STK[ToP].v.p.p = (char *) STK[ToP].v.p.p - STK[ToP + 1].v.ival;
if(EiC_traceON) {printf("subptrint\n"); }
874 break;
875 case subptr:
876 ToP--;
877 STK[ToP].v.ival =
878 (int) ((long) STK[ToP].v.p.p - (long) STK[ToP+1].v.p.p);
879 if(EiC_traceON) {printf("subptr\n"); }
880 break;
881
882 case drefptr:
883 drefTYPE(ptr_t, p); if(EiC_traceON) {printf("drefptr\n "); }
884 break;
885
886 case drefuptr:
887 drefTYPE(void**,p.p);
888 STK[ToP].v.p.sp = 0;
889 STK[ToP].v.p.ep = (void *) ULONG_MAX; if(EiC_traceON)
{printf("drefuptr \n");}
890 break;
891
892 case refptr: refTYPE(ptr_t, p); if(EiC_traceON) {printf("refptr
\n"); }
893 break;
894 case refuptr: refTYPE(void *, p.p); if(EiC_traceON)
{printf("refuptr\n ");}
895 break;
896
897 case stoptr: stoTYPE(p);/* if(EiC_traceON) {printf("stoptr
\n");}*/
898 break;
899 case stouptr: stoTYPE(p.p); if(EiC_traceON) {printf("stouptr \n");}
900 break;
901
902 case rvalptr: rvalTYPE(p); if(EiC_traceON) {printf("rvalptr \n");}
903 break;
904 case rvaluptr: rvalTYPE(p);
905 STK[ToP].v.p.sp = 0;
906 STK[ToP].v.p.ep = (void*) ULONG_MAX; /* set to a very high
value */
907 _if(EiC_traceON) {printf("rvaluptr ");}
908 break;
909
910 case pushptr: pushTYPE(p); /*if(EiC_traceON) {printf("pushptr
\n");}*/
911 break;
912 case ltptr: ltTYPE(p.p); if(EiC_traceON) {printf("ltptr\n");}
913 break;
914 case leptr: leTYPE(p.p); if(EiC_traceON) {printf("leptr \n");}
915 break;
916 case eqptr: eqTYPE(p.p); if(EiC_traceON) {printf("eqptr \n");}
917 break;
918 case neptr: neTYPE(p.p); if(EiC_traceON) {printf("neptr \n");}
919 break;
920 case gtptr: gtTYPE(p.p); if(EiC_traceON) {printf("gtptr \n");}
921 break;
114

Analyse dynamique de programmes C
922 case geptr: geTYPE(p.p); if(EiC_traceON) {printf("geptr \n");}
923 break;
924 case lorptr: lorTYPE(p.p); if(EiC_traceON) {printf("lorptr \n");}
925 break;
926 case landptr: landTYPE(p.p); if(EiC_traceON) {printf("landptr
\n");}
927 break;
928 case notptr: notTYPE(p.p); if(EiC_traceON) {printf("notptr \n");}
929 break;
930 case ptr2int: castTYPES(p.p, ival, int); if(EiC_traceON)
{printf("ptr2int \n");}
931 break;
932 case ptr2long: castTYPES(p.p, lval, long); if(EiC_traceON)
{printf("ptr2long \n");}
933 break;
934
935 case lval: /* on the fly safe pointer */
936 STK[ToP].v.p.p = &AR[InSt[p].ext][InSt[p].val.ival].v;
937 STK[ToP].v.p.ep = (char *) STK[ToP].v.p.p + (size_t)
938 InSt[p].val.p.ep;
939 STK[ToP].v.p.sp = STK[ToP].v.p.p;
940 _/*if(EiC_traceON) {printf("lval \n");}*/
941 break;
942 case assigntype: assignTYPE; /*if(EiC_traceON) {printf("assigntype
");}*/
943 break;
944 case stoval:
945 /*if(EiC_traceON) {printf("stoval "); }*/
946 switch(InSt[p].ext) {
947 case t_char:
948 case t_uchar: STK[ToP].v.cval = STK[ToP].v.ival;
if(EiC_traceON) {printf("t_char ou t_uchar\n");}
949 break;
950 case t_short:
951 case t_ushort: STK[ToP].v.sval = STK[ToP].v.ival;
if(EiC_traceON) {printf("t_short ou t_ushort\n");}
952 break;
953 case t_float: STK[ToP].v.fval = STK[ToP].v.dval;
if(EiC_traceON) {printf("t_float\n");}
954 /*_ case t_struct:
955 case t_union:
956 printf("stoVa1l with struct/union\n");
957 */
958 }
959
960 stoVAL;
961 break;
962 case pushval: pushVAL; if(EiC_traceON) {printf("pushval\n"); }
963 break;
964
965 case eiccall:
966 if(EiC_traceON) {printf("eiccall\n");}
967 if(!((symentry_t*)STK[ToP - 1].v.p.p)->tag) {
968 AdjustTop(6);
969 STK[ToP + 1].v.ival = p;
970 STK[ToP + 1].type = (void*)EiC_CurrentFile; /* save file */
971 STK[ToP + 2].v.p.p = InSt;
972 STK[ToP + 3].v.lval = AR[1] - env->LAR;
973 STK[ToP + 4].v.ival = env->lsp - STK[ToP].v.ival;
974 AR[1] = &env->LAR[env->lsp] /* - STK[ToP].v.ival] */ ;
975 code = ! STK[ToP - 1].v.p.p ? NULL :
976 AR[0][((symentry_t *)
977 STK[ToP - 1].v.p.p)->val.ival].v.p.p;
978
979 if (code == NULL) {
980 if(STK[ToP - 1].v.p.p) {
981 EiC_formatMessage("Link error: undefined function :->
%s\n",
115

Analyse dynamique de programmes C
982 ((symentry_t *) STK[ToP - 1].v.p.p)->id);
983 }
984 else
985 EiC_formatMessage("Link error: possible usage of a
function pointer"
986 " before assignment.\n");
987 env->lsp = 0;
988 raise(SIGINT);
989 }
990
991 /*printf("((symentry_t *)STK[%d - 1].v.p.p)->id = %s\n",ToP, ((symentry_t
*)STK[ToP - 1].v.p.p)->id);*/
992 EiC_CurrentFile = codeName(code);
993 _if(EiC_traceON) {printf("\n%s :\n# %d:%d\n\t%s %d
%d\n",(char*)EiC_CurrentFile,InSt[p].line,T[InSt[p].line].cptr_a,(char*)v.p.p,InSt[
p].line,T[InSt[p].line].cptr_a);}
994 InSt = code->inst;
995 p = -1;
996 ToP += 5;
997 if(EiC_traceON){
998 lastln = -1;
999 }
1000
1001 break;
1002 }
1003
1004 case call:
1005 if(EiC_traceON) {printf("\tCall %d %d
",InSt[p].line,T[InSt[p].line].cptr_a); }
1006 argc = ARGC;
1007 hold_AR = AR[2];
1008 hold_AR1 = AR[1];
1009 ARGC = STK[ToP].v.ival;
1010
1011 /*AR[2] = &env->LAR[env->lsp - ARGC];*/
1012 AR[2] = &env->LAR[env->lsp];
1013 if(InSt[p].ext)
1014 STK[ToP - 1].v = STK[ToP - 1].v.vfunc ();
1015 else
1016 STK[ToP - 1].v.vfunc();
1017
1018 env->lsp -= STK[ToP].v.ival;
1019 ARGC = argc;
1020 AR[2] = hold_AR;
1021 AR[1] = hold_AR1;
1022 ToP--;
1023 break;
1024
1025 case eicreturn:
1026 if(EiC_traceON) {printf("\tReturn %d %d
%d\n",STK[ToP].v.ival,InSt[p].line,T[InSt[p].line].cptr_a);}
1027 ToP -= 6; /* over write code pointer */
1028 p = STK[ToP + 2].v.ival;
1029
1030 EiC_CurrentFile = (char*)STK[ToP+2].type;
1031
1032 InSt = STK[ToP + 3].v.p.p;
1033 env->lsp = STK[ToP + 5].v.ival;
1034 STK[ToP].v = STK[ToP + 6].v;
1035
1036 AR[1] = &env->LAR[STK[ToP + 4].v.ival];
1037 if(EiC_traceON) {
1038
1039 EiC_eicpop(&names,&v);
1040 EiC_formatMessage("\n[%s] ", (char*)v.p.p);
1041 lastln = -1;
1042 }
1043 break;
116

Analyse dynamique de programmes C
1044
1045
1046 #if 1
1047 case eiclongjmp:
1048 {
1049
1050 _EiC_jmp_buf * reg;
1051
1052 reg = (_EiC_jmp_buf *) ((char*)STK[ToP].v.p.p -
STK[ToP+1].v.ival);
1053
1054 p = reg->p;
1055 EiC_CurrentFile = reg->file;
1056 InSt = reg->inst;
1057 env->lsp = reg->lsp;
1058 AR[1] = &env->LAR[reg->offset]; /*reg->ar; */
1059
1060 if(STK[ToP+1].v.ival == 0)
1061 STK[reg->top].v.ival = 1;
1062 else
1063 STK[reg->top].v.ival = STK[ToP+1].v.ival;
1064
1065 ToP = reg->top;
1066 if(EiC_traceON) {printf(" eiclongjmp \n");}
1067 }
1068
1069 break;
1070
1071 case eicsetjmp:
1072 {
1073
1074 _EiC_jmp_buf * reg;
1075
1076 reg = (_EiC_jmp_buf *) STK[ToP].v.p.p;
1077
1078 reg->p = p;
1079 reg->file = (void*)EiC_CurrentFile; /* save file */
1080 reg->inst = InSt;
1081 reg->lsp = env->lsp;
1082 reg->offset = AR[1] - env->LAR;
1083 reg->ar = AR[1];
1084 reg->top = ToP;
1085
1086 STK[ToP].v.ival = 0;
1087 _if(EiC_traceON) {printf(" eicsetjmp \n");}
1088 }
1089
1090 break;
1091 #endif
1092
1093 case massign:
1094 {
1095 val_t *v = &AR[InSt[p].ext][InSt[p].val.ival].v;
1096 v->p.sp = (void*)xcalloc(STK[ToP].v.ival,1);
1097 v->p.ep = (char*)v->p.sp + STK[ToP].v.ival;
1098 vp = NULL;
1099 if(EiC_traceON) {printf("massign "); }
1100 }
1101 break;
1102 case fmem: FMEM; if(EiC_traceON) {printf("fmem ");}
1103 break;
1104 case refmem: refMEM; if(EiC_traceON) {printf("refmem "); }
1105 break;
1106 case minit:
1107 memcpy(STK[ToP].v.p.p,InSt[p].val.p.p, InSt[p].ext);
1108 if(EiC_traceON) {printf("minit "); }
1109 break;
1110 case reducear:
117

Analyse dynamique de programmes C
1111 env->lsp -= InSt[p].val.ival;
1112 if(EiC_traceON) {printf("reducear "); }
1113 break;
1114 case checkar:
1115 {
1116 size_t d;
1117 ptrdiff_t d2;
1118 d = env->LARsize - env->lsp;
1119 if (d < InSt[p].val.ival) {
1120 /* printf("expanding AR %d\n",env->LARsize);*/
1121 d2 = (AR[1] - env->LAR);
1122 env->LARsize += InSt[p].val.ival - d;
1123 env->LAR =
1124 (AR_t *) xrealloc(env->LAR,
1125 env->LARsize * sizeof(AR_t));
1126 AR[1] = &env->LAR[(size_t) d2];
1127 }
1128 if (InSt[p].ext == 0) {
1129 env->lsp += InSt[p].val.ival;
1130 /*AR[1][0].v.p.p = NULL;*/
1131 }
1132 }
1133 /*if(EiC_traceON) {printf("checkar \n"); }*/
1134 break;
1135 case halt: STK[ToP].type = InSt[p].val.p.p;
1136 ON = 0; EiC_STaCK_VaLuE = STK[ToP].v; /*if(EiC_traceON)
{printf("\nhalt\n");}*/
1137 break;
1138
1139 case empty: /*if(EiC_traceON) {printf("empty\n");} */
1140 break;
1141 }
1142 p++;
1143 }
1144
1145
1146 end = clock();
1147
1148 /*if(EiC_traceON)
1149 EiC_messageDisplay("Fin d'interpre.c\n");
1150 */
1151 if(EiC_interActive)
1152 EiC_showvalue(&STK[ToP]);
1153
1154 if (EiC_TIMER) {
1155 fprintf(stdout," : %g\n",(endstart)/(float)CLOCKS_PER_SEC);
1156 }
1157
1158 xfree(STK);
1159 }
118

Analyse dynamique de programmes C
1 /* eicval.h
2 *
3 * (C) Copyright Apr 15 1995, Edmond J. Breen.
4 * ALL RIGHTS RESERVED.
5 * This code may be copied for personal, non-profit use only.
6 *
7 */
8
9 #ifndef EICVALH_
10 #define EICVALH_
11
12 #include
13 #include
14
15 #if !defined(_eic_ptr)
16 #define _eic_ptr
17 typedef struct {void *p, *sp, *ep;} ptr_t;
18 #endif
19
20
21 #ifndef NO_LONG_LONG
22 typedef long long eic_llong;
23 #else
24 typedef long eic_llong;
25 #endif
26
27
28 union VaL {
29 char cval; _ /* char value */
30 unsigned char ucval;
31 short sval; /* short integer val */
32 unsigned short usval;
33 int ival; _ /* integer value */
34 unsigned uival;
35 long lval; /* long integer */
36 unsigned long ulval;
37
38 /* long longs are not yet supported by ANSI C*/
39
40 eic_llong llval; /* long long value */
41
42 float fval; _ /* float value */
43 double dval; /* double float value */
44
45 ptr_t p; /* safe pointer */
46 void *up; /* unsafe pointer */
47
48 div_t divval;
49 ldiv_t ldivval;
50
51 int (*func)(); _ /* function pointer */
52 union VaL (*vfunc)();
53
54 struct symentry_t * sym;/* pointer into symbol table */
55
56 pid_t pid; /* process ID value */
57 size_t szval; /* generic size value */
58 ssize_t sszval; /* POSIX.1 byte count value */
59
60 mode_t mval; /* mode_t value */
61 #ifdef _NETBSD
62 long offval; /* file offset position */
63 #else
64 off_t offval; /* file offset position */
65 #endif
66 };
67
119

Analyse dynamique de programmes C
68 typedef union VaL val_t;
69
70
71 typedef struct Label_t {
72 char *name; /* label name */
73 int loc; /* label location */
74 struct Label_t *nxt; /* link to next label in list */
75 } Label_t;
76
77 typedef struct {
78 unsigned opcode;
79 val_t val;
80 int ext;
81 unsigned short line;
82 _ unsigned short pas; /* pour compter le nombre de passage*/
83 }InsT_t;
84
85
86 typedef struct {
87 unsigned int nextinst; /* next instruction */
88 unsigned int binst; /* physical size */
89 InsT_t * inst; /* instructions */
90 char * Filename; /* file with source code */
91 Label_t * labels;
92 Label_t * gotos;
93 void * parent; /* used for callbacks */
94 void * prev; /* used for chaining during reentry and callbacks*/
95 }code_t;
96
97 /* methods for code */
98 #define opcode(C,i) ((C)->inst[i].opcode)
99 #define setopcode(C,i,y) (opcode(C,i) = y)
100 #define ivalcode(C,i) ((C)->inst[i].val.ival)
101 #define pvalcode(C,i) ((C)->inst[i].val.p.p)
102 #define nextinst(C) ((C)->nextinst)
103 #define instline(C,i) ((C)->inst[i].line)
104 #define codeName(C) (C)->Filename
105
106
107 #ifndef EICH_
108 typedef struct AR_t {
109 val_t v;
110 type_expr * type;
111 _ unsigned short line;
112 }AR_t;
113
114 #else
115 typedef struct AR_t {
116 val_t v;
117 void * type;
118 unsigned short line;
119 }AR_t;
120 #endif
121
122 #endif
120

Analyse dynamique de programmes C
1
2 /* datastruct.h
3 *
4 * (C) Copyright May 7 1995, Edmond J. Breen.
5 * ALL RIGHTS RESERVED.
6 * This code may be copied for personal, non-profit use only.
7 *
8 */
9
10 #ifndef DATASTRUCT_H
11 #define DATASTRUCT_H
12
13 #if !defined(_eic_ptr) && !defined(_EiC)
14 #define _eic_ptr
15 typedef struct {void *p, *sp, *ep;} ptr_t;
16 #endif
17
18
19 #include "stab.h"
20
21 #include "eicval.h"
22
23
24 typedef struct {
25 int n;
26 val_t * val;
27 }eicstack_t;
28
29 typedef struct extern_t {
30 char * name;
31 type_expr * type;
32 int n;
33 unsigned *loc;
34 struct extern_t *nxt;
35 } extern_t;
36
37 /* methods for extern_t */
38 #define crt_extern() xcalloc(sizeof(extern_t),1)
39 #define getExtName(x) ((x)->name)
40 #define setExtName(x,y) ((x)->name = y)
41 #define getExtType(x) ((x)->type)
42 #define setExtType(x,y) ((x)->type = y)
43 #define getExtNext(x) ((x)->nxt)
44 #define setExtNext(x,y) ((x)->nxt = y)
45
46
47 typedef struct {
48 char cl; /* closed flag */
49 int n; /* number of members */
50 int tsize; /* total size in bytes of struct */
51 int align; /* alignment of structure */
52 type_expr **type; /* member types */
53 char **id; /* member names */
54 int *offset; /* offsets to members data position*/
55 int ntags; /* number of tags */
56 type_expr **tag; /* tag types */
57 }struct_t;
58
59
60 typedef struct {
61 unsigned short Tok;
62 int Tab;__ /* name space table */
63 unsigned char Pflag; /* processed flag */
64 unsigned char Sclass; /* storage class */
65 unsigned char Typequal; /* type qualifier */
66 struct symentry_t * Sym;
67 code_t Code;
68 type_expr * Type;
121

Analyse dynamique de programmes C
69 val_t Val;
70 }token_t;
71
72 /*****
73 #define getTokenVal(x) ((x).Val)
74 #define setTokenVal(x,y) ((x).Val = (y))
75 #define getTokenType(x) ((x).Type)
76 #define setTokenType(x,y) ((x).Type = (y))
77 #define getTokenCode(x) ((x).Code)
78 #define setTokenCode(x,y) ((x).Code = (y))
79 #define getTokenSym(x) ((x).Sym)
80 #define setTokenSym(x,y) ((x).Sym = (y))
81 #define getTokenTypequal(x) ((x).Typequal)
82 #define setTokenTypequal(x,y) ((x).Typequal = (y))
83 #define getTokenSclass(x) ((x).Sclass)
84 #define setTokenSclass(x,y) ((x).Sclass = (y))
85 #define getTokenPflag(x) ((x).Pflag)
86 #define setTokenPflag(x,y) ((x).Pflag = (y))
87 #define getTokenTab(x) ((x).Tab)
88 #define setTokenTab(x,y) ((x).Tab = (y))
89 #define getTokenTok(x) ((x).Tok)
90 #define setTokenTok(x,y) ((x).Tok = (y))
91 ********/
92
93
94
95 /*CUT symEntry*/
96 typedef struct symentry_t {
97 int tag; /* maker */
98 unsigned int entry; /* entry number */
99 struct symentry_t *next; /* link to next symentry */
100 char *id; /* pointer to identifier string */
101 unsigned char sclass; /* storage class code */
102 unsigned char typequal; /* type qualifier */
103 unsigned char level; /* scope level */
104 unsigned char nspace; /* name space identifier */
105 char ass; /* used to flag assignment */
106 type_expr * type; /* object type */
107 val_t val; /* symbol value information */
108 char *pname; /* previous file name */
109 char *fname; /* file name pointer */
110
111 #if 0
112 int calls; /* number of local references made */
113 int Nref;
114 struct symentry_t **ref; /* references */
115 #endif
116
117 }symentry_t;
118 /*END CUT*/
119
120 typedef struct {
121 stab_t stab;
122
123 code_t CODE;
124 eicstack_t ARgar; /* for garbage collection of AR units*/
125 unsigned int ARsize,sp;
126 AR_t *AR; __ /* static activation record */
127 unsigned int LARsize,lsp;
128 AR_t *LAR;
129 extern_t *link;
130
131 }environ_t;
132
133 #define getenvcode(env) ((env)->CODE)
134
135 typedef struct {
136 int n; /* number of enumerators */
122

Analyse dynamique de programmes C
137 int *eval; /* array of enumerator values */
138 symentry_t **syms; /* list of symbol tabel entries */
139 }enum_t;
140
141 typedef struct {
142 int hsize;
143 symentry_t **htab;
144 }hashtab_t;
145
146 #endif
123

Analyse dynamique de programmes C
1 /* global.h
2 *
3 * (C) Copyright May 7 1995, Edmond J. Breen.
4 * ALL RIGHTS RESERVED.
5 * This code may be copied for personal, non-profit use only.
6 *
7 */
8 #ifndef GLOBALH
9 #define GLOBALH
10
11 #define DONE 0
12 #define BSIZE 128
13 #define NONE -1
14 #define EOS '\0'
15 #define TRUE 1
16 #define FALSE 0
17
18 typedef enum {/* the order of members in obj_t is important as it is
19 * reflected in the binary operator function table BINFUN in
20 * typesets.c
21 */
22 t_error, t_bool, t_char, t_uchar, t_short, t_ushort, /*5*/
23 t_int, t_enum, t_uint, t_long, t_ulong, t_llong, /*11*/
24 t_float, /*12*/
25 t_double, t_pointer, t_void, t_struct, t_union, /*17*/
26 t_lval, t_array, t_func, t_funcdec, t_elem, t_eic, /*23*/
27 t_builtin, t_var, t_hidden, t_ref
28 } obj_t;
29
30 /* unsafe macros */
31 #define isArithmetic(t) (t >= t_char && t = t_char && t

Analyse dynamique de programmes C
68 /*CUT nameSpaceCodes*/
69 extern int EiC_work_tab;
70 enum{ /* name space codes */
71 eic_tab, /* name space for EiC commands */
72 stand_tab, /* name space for basic variables */
73 tag_tab, /* name space for struct/union and enumeration tags */
74 lab_tab /* name space for goto labels */
75 };
76 /*END CUT*/
77
78 enum {eickmark, eicgstring, eicstay};
79
80
81 #endif
125

This document was created with Win2PDF available at http://www.daneprairie.com.
The unregistered version of Win2PDF is for evaluation or non-commercial use only.