Upload
maria-del-rosario-paez-palma
View
212
Download
0
Embed Size (px)
Citation preview
ANNOTATIONS FOR (MORE)PRECISE POINTS-TO ANALYSIS
Diego Garbervetsky, Mike Barnett, Manuel Fähndrich, Francesco Logozzo
Objetivos
Extender el análisis de grafos Points-to para .NET (parámetros por referencia y estructuras).
Incrementar la precisión en el análisis de efectos de métodos no analizables.
Definiciones
Método no analizable Un método es no analizable si su código
no está disponible.
Método débilmente puro Un método es débilmente puro si no
“muta” ninguna locación existente en el estado correcto anterior a la invocación del método.
El problema
List<int> Copy(IEnumerable<int> src)
{
List<int> l = new List<int>();
IEnumerator<int> iter = src.GetEnumerator();
while (iter.MoveNext()){
int x = iter.get_Current();
l.Add(x);
}
return l;
}
Salcianu
Muy conservador: no puede analizar llamadas a métodos de interfaces, porque src e iter podrían escapar a cualquier
posición en memoria (tipado dinámico) el método tiene una (potencial) escritura
a cualquier posición accesible, como las variables estáticas.
Extensiones para .NET
Address nodes Representan objetos y estructuras.
Un address node que representa un objeto tiene ejes salientes con etiqueta *.
Un address node para valores de estructuras tiene un eje saliente por campo (la etiqueta es el nombre del campo).
Ejemplo: v1 = v2(estructura)
&v0 &v1
&f1 &f2
&g i2
i1
*
*
*
f1 f2
g
Ejemplo: v1 = v2(antes)
&v1
&f1 &f2
&g i2
i1
*
*
f1 f2
g
&v2
&f1 &f2
&g i4
i3
*
*
f1 f2
g
Ejemplo: v1 = v2(después)
&v1
&f1 &f2
&g
*
*
f1 f2
g
&v2
&f1 &f2
&g i4
i3
*
*
f1 f2
g
Métodos no analizables
Supongamos que tenemos un método no analizable, del que solamente sabemos que escribe sobre todo objeto alcanzable por el parámetro: m2(p1)
p1.f1 = o; p1.f1.f2 = o; p1.f1.f2…fn = o;
Tenemos además otro método del que tenemos información solamente sobre a1.f1, y este método llama a m2: m1()
… m2(a1);
Métodos no analizables
Sería un error considerar los efectos de m2 solo sobre a1.f1.
Tenemos información insuficiente sobre el contexto de m1.
Necesitamos un mecanismo para hacer que los efectos del método llamado persistan en el contexto del método llamador, y así actualizar a1 cuando dispongamos de más información.
Extensiones para métodos no analizables (nodos)
Omega nodes (ω) Modelan el conjunto de nodos alcanzables
desde ese nodo.
Omega Confined nodes (ωC) Subcojunto de ω. Son nodos ω que
representan solo aquellos alcanzables por los campos propios del llamador.
La clase T es dueña del campo f si el objeto O de tipo T es dueño del objeto apuntado por su campo f.
Extensiones para métodos no analizables (ejes)
Ejes “?” Representan cualquier campo existente.
Ejes “$” Campos no propios. Permite distinguir entre
referencias a objetos que pueden ser escritos por el método y los que únicamente pueden ser leídos.
Matcheo interprocedural
Matcheo con ω: calculamos el conjunto de nodos (del llamador) alcanzables desde este, y finalmente todos los load nodes se convierten en ω.
Matcheo con ωC: consideramos solo caminos que pasan por los ejes “?” y los ejes propios. Rechazamos los que contienen ejes “$”.
Ejemplo: omega nodes(método llamado)
&p2
&
ω2ω1
&p1
* *
*?
Ejemplo: omega nodes(método llamador)
&f1
IN2
IN1
&a1
*
*
f1&f2
L4
IN3
&a2
*
*
f2
Ejemplo: omega nodes(bindeando)
&f1
IN2
IN1
&a1
*
*
f1&f2
L4
IN3
&a2
*
*
f2
&
&
?
*
*
*
?
*
Ejemplo: omega nodes(bindeando)
&f1
IN2
IN1
&a1
*
*
f1&f2
ωL4
IN3
&a2
*
*
f2
&
&
?
*
*
*
?
*
Ejemplo: omega nodes(bindeado)
&f1
IN2
IN1
&a1
*
*
f1&f2
ωL4
IN3
&a2
*
*
f2
&
&
?
*
*
*
?
*
Anotaciones
Conclusiones
Se logró extender el analisis de Salcianu para Soportar el modelo de memoria de .NET Tratar los métodos no analizables de
manera más precisa Mediante los nodos omega y el lenguaje
de anotaciones
Verificaciones con la especificación es suficientemente simple utilizando el lenguaje de anotaciones.
Preguntas??