• Aucun résultat trouvé

Contributions

Dans le document Analyse des pointeurs pour le langage C (Page 32-34)

Nous présentons dans cette section les principales contributions de la thèse qui sont 1) la prise en compte de toutes les instructions du langage C, 2) la conception d’une analyse intrapro- céurale précise et 3) un analyse interprocédurale ascendante locale.

1.4.1

Traiter toutes les instructions du langage C ?

Notre analyse de pointeurs permet de traiter toutes les instructions du langage C. Cependant, toutes ces instructions n’ont pas le même effet sur l’analyse. L’instruction principale génératrice d’arcs points-to est l’assignation avec en partie gauche un pointeur. Mais les autres instruc- tions ont quand même des effets de bord sur les arcs points-to, comme par exemple l’arithmé- tique de pointeurs, les appels de fonctions, ou encore les structures de contrôle. Comme toutes les instructions en C sont aussi des expressions et qu’il est possible d’en combiner plusieurs, par exemple ++a[i-j], il a fallu respecter la priorité des opérateurs ainsi que les points de sé-

1.4. Contributions 7

quence4. Grâce à une représentation interne proche du langage, notre analyse effectue le calcul des arcs points-to en une seule passe, sans décomposer les expressions. Elle prend en compte les tableaux et les structures de données de type struct. Cependant, les unions et les enum ne sont pas encore pris en compte dans la version actuelle. Quant aux « cast » ils ne sont pris en compte que partiellement.

1.4.2

Concevoir une analyse intraprocédurale précise

La contribution la plus importante de notre travail est notre analyse intraprocédurale. C’est une analyse sensible au flot de contrôle ; c’est-à-dire que les arcs points-to sont mis à jour d’un point programme à un autre, ce qui garantit un résultat précis permettant la prise de décision des autres analyses. L’analyse prend aussi en compte les structures de contrôle et introduit une approximation sur les relations pour exprimer l’incertitude due aux conditions. Notre analyse prend en entrée un programme traduit dans la représentation interne du compilateur PIPS [JT89] et se déroule en une seule passe sans décomposer les instructions complexes, contrairement à l’analyse d’Emami [Ema93].

Garantir la précision des résultats intraprocéduraux a ainsi permis de répondre aux besoins des analyses clientes comme le montre le chapitre 2.

1.4.3

Concevoir une analyse interprocédurale modulaire

Adopter la même approche pour l’analyse interprocédurale, qui consiste à propager en avant l’information points-to pour tout le programme, aurait provoqué la dégradation des résultats et des performances (temps d’exécution). Si une analyse sensible au contexte avait été adoptée, les résultats obtenus auraient été très précis mais au prix d’un temps d’exécution considérable et d’une grande complexité. En effet, réanalyser une fonction à chacun de ses appels est une mau- vaise solution, surtout si la précision accrue de cette approche n’améliore pas significativement les résultats des analyses clientes.

Pour minimiser les réanalyses, Wilson [WHI95] a proposé d’accumuler pour chaque fonction des résumés pouvant être réutilisés lors des sites d’appels ultérieurs dans la mesure où l’aliasing de deux sites d’appel est identique. Malheureusement, Wilson n’a donné d’information précise ni sur ses résumés ni sur les algorithmes nécessaires à leur utilisation.

Notre analyse est fondamentalement différente parce qu’elle est ascendante afin de limiter le volume des structures de données à manipuler. Elle nécessite d’une part une hypothèse forte de non aliasing5des paramètres formels et des variables globales, et d’autre part un mécanisme de transformeur de points-to, remplissant la même fonction que les résumés de Wilson.

Pour chaque fonction et après une analyse de son corps, nous créons un transformeur des arcs points-to qui peut être transmis au niveau de l’appelant.

Ce transformeur contient simultanément des information sur les relations points-to en entrée et sortie de procédure, sur les pointeurs modifiés et sur les cellules mémoire libérées alors que le résumé de Wilson ne comporte que l’effet de la procédure sur les arguments et leur cibles, qui peuvent être de type pointeur aussi. Seules les variables visibles au niveau du site d’appel sont conservées ; ces variables incluent les valeurs de retours, les paramètres formels pouvant conte- nir des pointeurs (pointeur, structure, tableau de pointeurs), les variables globales et les variables allouées au niveau du tas. Ce mécanisme permet de mettre à jour le site d’appel, de garder une liste d’arcs points-to pertinents et surtout d’offrir une analyse de pointeurs performante.

4. Voir la section 5.1.2.3 de la norme C

8 Chapitre 1. Introduction

1.4.4

Répondre aux besoins des applications scientifiques

La meilleure analyse de pointeurs n’est pas celle qui fournit les résultats les plus précis, ni celle qui s’exécute rapidement mais plutôt celle qui répond à des besoins bien spécifiques. En effet, concevoir une analyse précise alors que les applications qu’elles ciblent ne nécessitent que des approximations sur les pointeurs est une erreur de conception.

Notre analyse répond aux besoins des applications scientifiques, décrites précédemment au niveau de la sous-section 1.2.1 ainsi que par les travaux suivants [Rak01], [GH98], [HHN92], [ADLL05]. Le but est de cibler les analyses clientes comme l’analyse de variables vivantes, la détection de code mort ou inutile ou encore l’analyse de dépendances. Une première étude a été faite sur les besoins des applications [Ami08] afin de repérer les structures les plus récurrentes et d’orienter le choix de l’analyse points-to qui répond le mieux aux profils de ces applications. Les structures les plus fréquentes sont les pointeurs sur tableaux, les tableaux dynamiques créés au niveau du tas ainsi que les boucles imbriquées.

1.4.5

Modéliser l’allocation dynamique au niveau du tas

Malgré l’absence de « shape analysis » dans notre analyse, celle-ci apporte une précision sur les sites d’allocation dynamique et la modélisation du tas [Ghi96]. Cette précision est para- métrable ; le tas peut être considéré comme un objet unique et donc tous les pointeurs alloués via la routine malloc pointent vers la même destination *heap* ou bien les pointeurs ciblent non seulement le tas mais aussi la ligne à laquelle malloc a été appelée ainsi que le nom du module en cours. La modélisation du tas est détaillée dans le chapitre 5.

Dans le document Analyse des pointeurs pour le langage C (Page 32-34)