Vorlesung Software-Reengineering

Transkript

1 Vorlesung Software-Reengineering Prof. Dr. Rainer Koschke Arbeitsgruppe Softwaretechnik Fachbereich Mathematik und Informatik Universität Bremen Wintersemester 2011/12 Überblick I Statische Programmanalyse

2 Statische Programmanalyse: Statische Programmanalyse I Statische Programmanalyse Compiler versus Reengineering-Werkzeug Lexikalische Ebene Syntaktische Ebene Abstrakte Syntax Traversierungen von ASTs Quellennahe Repräsentation Kontrollfluss Kontrollabhängigkeit Datenabhängigkeit Datenflussanalyse: Bestimmung von Set Kontrollflussgraph Lokale Datenflussanalyse Globale Datenflussanalyse Iterative Lösung der Gleichungen Worklist-Algorithmus Terminierung des Algorithmus 3 / 99 Statische Programmanalyse: Statische Programmanalyse II Static Single Assignment Form Aliasing Analysemöglichkeiten Wiederholungsfragen 4 / 99

3 Statische Programmanalyse: Wegweiser Kontext Am Anfang steht die Analyse: statische Analyse dynamische Analyse Welche Informationen kann man wie aus Programmen statisch extrahieren? Welche Formen der statischen Programmrepräsentationen und -analysen gibt es? Worin unterscheidet sich die Programmanalyse im Compilerbau von der im Reengineering? 5 / 99 Statische Programmanalyse: Compiler versus Reengineering-Werkzeug Compiler-Struktur Programmtext mit Makros Präprozessor Lexer Programmtext Tokenstrom Parser abstrakter Syntaxbaum semantische Analyse annotierter abstrakter Syntaxbaum Front-End Zwischensprachengenerator Zwischendarstellung Analysen u. Optimierungen optimierte Zwischendarstellung Middle- End Codegenerator Code Back-End 6 / 99

4 Statische Programmanalyse: Compiler versus Reengineering-Werkzeug Analysator- und Transformator-Struktur Programmtext Programmtext mit Makros Präprozessor Lexer Tokenstrom Parser abstrakter Syntaxbaum semantische Analyse annotierter abstrakter Syntaxbaum Front-End Zwischensprachengenerator Zwischendarstellung Analysen Transformationen annotierte Zwischendarstellung Middle- End Unparser Programmtext Back-End Wissensbasis 7 / 99 Phasen eines Compilers Wissen über das Programm nimmt zu syntaktische Dekomposition semantische Attributierung Namensbindung Kontrollflussinformation Datenflussinformation Abstraktion nimmt ab abstrakter Syntaxbaum maschinennahe einheitliche Zwischensprache, z.b. Register Transfer Language (RTL) von Gnu GCC Maschinensprache

5 Statische Programmanalyse: Compiler versus Reengineering-Werkzeug Unterschiede Compiler / Analysator lokal global optimistisch pessimistisch quellennah sprachenunabhängig 8 / 99 Statische Programmanalyse: Lexikalische Ebene Token (Lexem) Definition Ein Token (auch: Lexem) ist die kleinste unteilbare Einheit, die in einer Programmiersprache von Bedeutung ist: Schlüsselwörter Bezeichner Literale (Zahlen, Zeichenketten, einzelne Zeichen) Üblicherweise keine Tokens: Whitespace Kommentare Übliche Attribute: Typ (meist codiert als Zahl oder Aufzählungswert) Quellcodeposition (Dateiname, Zeile, Spalte) Wert (textuelle Repräsentation) 10 / 99

6 Statische Programmanalyse: Lexikalische Ebene Der Tokenstrom 1 { i n t x ; 2 i n t y ; 3 y = 0 ; 4 x = y + 1 ; 5 } Zeile Spalte Typ-Code Typ Wert { { INT int ID x ; ; INT int ID y ; ; ID y = = NUMBER ; ; ID x = = ID y NUMBER ; ; } } 11 / 99 Statische Programmanalyse: Lexikalische Ebene Reguläre Grammatik 1 // R e g u l a r e x p r e s s i o n s to be used i n token d e f i n i t i o n s 2 fragment SPACE : \ t ; 3 fragment LETTER LOWER : ( a.. z ) ; 4 fragment LETTER UPPER : ( A.. Z ) ; 5 fragment DIGIT : ( ) ; 6 fragment LETTERS : (LETTER LOWER LETTER UPPER) ; 7 8 // Whitespace to be i g n o r e d 9 NEWLINE : ( \ r? \ n )+ { $ c h a n n e l = HIDDEN ; } ; 10 WHITESPACE : SPACE+ { $ c h a n n e l = HIDDEN ; } ; 11 COMMENT : //. \ n { $ c h a n n e l = HIDDEN ; } ; // Token d e f i n i t i o n s 14 NUMBER : DIGIT +; 15 INT : i n t ; 16 ID : (LETTERS ) ( LETTERS DIGIT ) ; 12 / 99

7 Statische Programmanalyse: Lexikalische Ebene Generierung des Lexers Reguläre Grammatik // R e g u l a r e x p r e s s i o n s to be used i n token d e f i n i t i o n s fragment SPACE : \ t ; fragment LETTER LOWER : ( a.. z ) ;... INT : i n t ; ID : (LETTERS ) ( LETTERS DIGIT ) ; Lexergenerator: antlr, (f)lex, javacc,... Lexer (z.b. in C, C++, Java, Ada,... ) 13 / 99 Statische Programmanalyse: Lexikalische Ebene Verwendung des Lexers (AntLR) 1 F i l e R e a d e r r e a d e r = new F i l e R e a d e r ( a r g s [ 0 ] ) ; 2 ANTLRReaderStream i n p u t = new ANTLRReaderStream ( r e a d e r ) ; 3 SATLexer l e x e r = new SATLexer ( i n p u t ) ; 4 r e a d e r. c l o s e ( ) ; 5 CommonTokenStream tokenstream = new CommonTokenStream ( l e x e r ) ; 6 7 f o r ( Object o b j : tokenstream. gettokens ( ) ) { 8 CommonToken token = ( CommonToken ) o b j ; 9 i f ( token. g e tchannel ( )!= CommonToken. HIDDEN CHANNEL) { 10 System. out. p r i n t f 11 ( %d:%d token : %d name : %s v a l u e ( t e x t ) : %s \ n, 12 token. g e t L i n e ( ), 13 token. g e t C h a r P o s i t i o n I n L i n e ( ) + 1, 14 token. gettype ( ), 15 SATParser. tokennames [ token. gettype ( ) ], 16 token. gettext ( ) ) ; 17 } 18 } 14 / 99

8 Statische Programmanalyse: Syntaktische Ebene Syntaxanalyse Grammatiken definieren Programmiersprachensyntax mit Regeln (BNF oder EBNF) Grammatikregel α 0 : α 1 α 2... α n ; α i Σ Ω Definition Nichtterminale Ω: Symbole, die auf linker Seite einer Regel auftreten Definition Terminale Σ: Symbole, die auf keiner linken Seite einer Regel auftreten Tokens 16 / 99 es gibt verschiedene Grammatikklassen (LALR(k), LL(k), LR(k),... ) nicht für jede Programmiersprache gibt es eine offizielle Grammatik (z.b. VisualBasic 6)

9 Statische Programmanalyse: Syntaktische Ebene Beispielgrammatik in EBNF 1 b l o c k : { d e c l s stmts } ; 2 3 d e c l s : d e c l ; d e c l s ; 4 d e c l : t y p e ID ; 5 t y p e : INT ; 6 7 stmts : stmt o p t s t m t s ; 8 o p t s t m t s : stmts ; 9 10 stmt : ID = e x p r ; 11 b l o c k 12 ; e x p r : term ( ( + ) term ) ; 15 term : p r i m a r y ( ( / ) p r i m a r y ) ; 16 p r i m a r y : NUMBER 17 ID 18 ( e x p r ) 19 ; 17 / 99 Statische Programmanalyse: Syntaktische Ebene Konkreter Syntaxbaum Definition Konkreter Syntaxbaum (auch: Ableitungsbaum oder Parsebaum): Herleitung einer Eingabe anhand angewandter Grammatikregeln. Innere Knoten: Nichtterminale der angewandten Regeln Blätter: Terminale oder das leere Wort ɛ Links-Rechts-Traversierung mit Ausgabe der Blätter liefert das Originalprogramm 18 / 99

10 Statische Programmanalyse: Syntaktische Ebene Beispiel für konkreten Syntaxbaum 1 { i n t x ; 2 i n t y ; 3 y = 0 ; 4 x = y + 1 ; 5 } Tokenstrom: { INT ID ( x ) ; INT ID ( y ) ; ID ( y ) = NUMBER ( 0 ) ; ID ( x ) = ID ( y ) + NUMBER ( 1 ) ; } 20 / 99 Statische Programmanalyse: Syntaktische Ebene Beispiel eines konkreten Syntaxbaums 21 / 99

11 Statische Programmanalyse: Syntaktische Ebene Der Parser Grammatik 1 b l o c k : { d e c l s stmts } ; p r i m a r y : NUMBER 5 ID 6 ( e x p r ) 7 ; Parsergenerator: AntLR, yacc, bison, cocktail95, JavaCC,... Parser 22 / 99 Statische Programmanalyse: Syntaktische Ebene Verwendung des Parsers (AntLR) 1 tokenstream = new TokenRewriteStream ( l e x e r ) ; 2 SATParser p a r s e r = new SATParser ( tokenstream ) ; 3 4 SATParser. b l o c k r e t u r n r = p a r s e r. b l o c k ( ) ; 5 CommonTree c t = ( CommonTree ) r. g e t T r e e ( ) ; 6 7 System. out. p r i n t l n ( #l e a v e s : + c t. g e t C h i l d C o u n t ( ) ) ; 8 System. out. p r i n t l n ( c t. t o S t r i n g T r e e ( ) ) ; 23 / 99

12 Statische Programmanalyse: Syntaktische Ebene Datenstrukturen für konkreten Syntaxbaum 1 p u b l i c a b s t r a c t c l a s s Node { } 2 3 p u b l i c a b s t r a c t c l a s s D e c l s e x t e n d s Node { } 4 5 p u b l i c c l a s s D e c l s 1 e x t e n d s D e c l s { 6 p r i v a t e Decl d e c l ; 7 p r i v a t e CommonToken s e m i c o l o n ; 8 p r i v a t e D e c l s d e c l s ; 9 10 p u b l i c D e c l s 1 ( Decl d e c l, CommonToken s e m i c o l o n, D e c l s d e c l s ) { 11 t h i s. d e c l = d e c l ; 12 t h i s. s e m i c o l o n = s e m i c o l o n ; 13 t h i s. d e c l s = d e c l s ; 14 } 15 } p u b l i c c l a s s D e c l s 2 e x t e n d s D e c l s { } 24 / 99 Statische Programmanalyse: Abstrakte Syntax Abstrakter Syntaxbaum Definition Abstrakter Syntaxbaum (engl. Abstract Syntax Tree AST) ist eine strukturerhaltende (homomorphe) Abstraktion des konkreten Syntaxbaums. 25 / 99

13 Wovon abstrahiert wird, ist anwendungsspezifisch. Einfache Abstraktionen: Vermeidung von Ketten Sequenzen ersetzen Links- und Rechtsrekursionen irrelevante Terminale Weitergehende Abstraktionen: charakteristische Blätter werden zu inneren Knoten Normalisierungen (z.b. a!= b wird zu!(a==b)) Unifizierungen (s.u.) Statische Programmanalyse: Abstrakte Syntax Beispiel eines abstrakten Syntaxbaums 1 { i n t x ; 2 i n t y ; 3 y = 0 ; 4 x = y + 1 ; 5 } decls block 1:1 stmts 0:0 0:0 var_decl y var_decl x = = 1:6 2:6 3:4 4:4 int int id y literal 0 id x + 1:2 2:2 3:2 3:6 4:2 4:8 id y 4:6 literal 1 4:10 26 / 99

14 Statische Programmanalyse: Abstrakte Syntax Abstrakter Syntaxgraph (Attributierung des AST) Definition Syntaktische Kanten repräsentieren syntaktische Dekomposition (bilden Baum). Definition Semantische Kanten: alle ergänzenden Kanten, die semantische Verweise auf andere Knoten repräsentieren. Z.B. Namensverwendung Deklaration Definition Abstract Syntax Graph (ASG): syntaktische + semantische Kanten 27 / 99 Statische Programmanalyse: Abstrakte Syntax Beispiel eines abstrakten Syntaxbaums block 1:1 decls stmts 0:0 0:0 var_decl y var_decl x = = 1:6 2:6 3:4 4:4 decl decl int 1:2 int 2:2 decl id y 3:2 literal 0 3:6 id x 4:2 + 4:8 id y literal 1 4:6 4:10 28 / 99

15 Statische Programmanalyse: Abstrakte Syntax Abstrakte Syntax definiert Struktur aller ASTs Decls Node Seq # children : list of Node Stmts Type Int Expr Binary + left : Expr + right : Expr Plus Minus Atomic Literal + value : int Unary + operand : Expr ID + decl : Decl // semantic + name : string Stmt Assign + lhs : Expr + rhs : Expr Decl Var_Decl + name : string + type : Type Block + decls : Decls + stmts : Stmts 29 / 99 Statische Programmanalyse: Traversierungen von ASTs Traversierungen des ASTs Definition Explizite Traversierungen: Besuchsreihenfolge wird vom Programmierer selbst festgelegt bzw. ist vordefiniert. Tiefensuche Postorder Preorder Breitensuche z.b. Entwurfsmuster Visitor Definition Implizite Traversierungen: Besuchsreihenfolge ergibt sich aus der Berechnung. z.b. Attributgrammatiken 30 / 99

16 Statische Programmanalyse: Traversierungen von ASTs Visitor Pattern Problem: ein Algorithmus soll alle Knoten im AST besuchen und behandeln. Beispiel: Unparse. Anforderungen: alle Knoten im AST müssen besucht werden jeder Knotentyp muss individuell behandelt werden können die Besuchsreihenfolge kann variieren weitere solche Algorithmen sollen einfach hinzugefügt werden können, ohne dass die Klassen der AST-Knoten geändert werden müssen Lösung: Visitor-Pattern 31 / 99 Statische Programmanalyse: Traversierungen von ASTs AST Visitor Pattern... <<interface>> Visitor +visit_stmts() +visit_var_decl() +visit_plus()... +visit_block() Simple_Visitor +visit_stmts() +visit_var_decl() +visit_plus()... +visit_block() +visit_stmts() +visit_var_decl() +visit_plus()... +visit_block() Node visits * * +accept(visitor) <<realizes>> Unparse_Visitor Seq # children : list of Node Type Expr Stmt Int Binary + left : Expr + right : Expr Atomic Unary Decls + operand : Expr Assign + lhs : Expr + rhs : Expr + accept(visitor) Decl Block Stmts + accept(visitor v) + decls : Decls + stmts : Stmts + accept(visitor) + accept(visitor v) + accept(visitor v) Plus + accept(visitor v) Minus + accept(visitor v) Literal + value : int + accept(visitor) ID + decl : Decl // semantic + name : string + accept(visitor) Var_Decl + name : string + type : Type + accept(visitor) v.visit_minus(this) v.visit_plus(this) 32 / 99

17 Beteiligte: AST-Knoten werden besucht deklarieren eine accept-operation, die die entsprechende visit-operation aufrufen Visitor (Interface): Schnittstelle für alle Visitors deklariert eine visit-operation für jeden konkreten AST-Knotentyp Simple-Visitor implementiert Visitor Standardimplementierung mit fester Besuchsreihenfolge konkreter Visitor leitet von Simple-Visitor ab überschreibt ererbte visit-operation abhängig von Aufgabe Statische Programmanalyse: Traversierungen von ASTs Unparse mit Visitor: besuchbare AST-Knoten 1 p u b l i c a b s t r a c t c l a s s Node { 2 p r i v a t e i n t l i n e ; 3 p r i v a t e i n t column ; 4 p u b l i c a b s t r a c t v o i d a c c e p t ( V i s i t o r v i s i t o r ) ; 5 } 6 7 p u b l i c a b s t r a c t c l a s s Expr e x t e n d s Node { } 8 9 p u b l i c a b s t r a c t c l a s s B i n a r y e x t e n d s Expr { 10 p u b l i c Expr l e f t ; 11 p u b l i c Expr r i g h t ; 12 } p u b l i c c l a s s P l u s e x t e n d s B i n a r y { 15 p u b l i c v o i d a c c e p t ( V i s i t o r v i s i t o r ) { 16 v i s i t o r. v i s i t p l u s ( t h i s ) ; 17 } 18 } 33 / 99

18 Statische Programmanalyse: Traversierungen von ASTs Unparse mit Visitor: Visitor-Interface 1 p u b l i c i n t e r f a c e V i s i t o r { 2 3 p u b l i c v o i d v i s i t m i n u s ( Minus node ) ; 4 p u b l i c v o i d v i s i t p l u s ( P l u s node ) ; p u b l i c v o i d b e f o r e m u l t ( Mult node ) ; 9 p u b l i c v o i d b e f o r e p l u s ( P l u s node ) ; p u b l i c v o i d a f t e r m i n u s ( Minus node ) ; 13 p u b l i c v o i d a f t e r p l u s ( P l u s node ) ; 14 } 34 / 99 Statische Programmanalyse: Traversierungen von ASTs Unparse mit Visitor: Standardimplementierung 1 p u b l i c c l a s s S i m p l e V i s i t o r implements V i s i t o r { 2 3 p r i v a t e v o i d v i s i t b i n a r y ( B i n a r y node ) { 4 node. g e t L e f t ( ). a c c e p t ( t h i s ) ; 5 node. g e t R i g h t ( ). a c c e p t ( t h i s ) ; 6 } 7 p u b l i c v o i d v i s i t m i n u s ( Minus node ) { 8 b e f o r e m i n u s ( node ) ; 9 v i s i t b i n a r y ( node ) ; 10 a f t e r m i n u s ( node ) ; 11 } 12 p u b l i c v o i d v i s i t p l u s ( P l u s node ) { 13 b e f o r e p l u s ( node ) ; 14 v i s i t b i n a r y ( node ) ; 15 a f t e r p l u s ( node ) ; 16 } / 99

19 Statische Programmanalyse: Traversierungen von ASTs Unparse mit Visitor: Standardimplementierung p u b l i c v o i d b e f o r e m i n u s ( Minus node ) { } 3 p u b l i c v o i d b e f o r e p l u s ( P l u s node ) { } p u b l i c v o i d a f t e r m i n u s ( Minus node ) { } 6 p u b l i c v o i d a f t e r p l u s ( P l u s node ) { } / 99 Statische Programmanalyse: Traversierungen von ASTs Unparse mit Visitor: Unparse-Implementierung 1 p u b l i c c l a s s Unparser e x t e n d s S i m p l e V i s i t o r { 2 3 p r i v a t e v o i d v i s i t b i n a r y ( B i n a r y node, S t r i n g op ) { 4 node. l e f t. a c c e p t ( t h i s ) ; 5 System. out. p r i n t ( op ) ; 6 node. r i g h t. a c c e p t ( t h i s ) ; 7 } 8 9 p u b l i c v o i d v i s i t m i n u s ( Minus node ) { 10 v i s i t b i n a r y ( node, ) ; 11 } p u b l i c v o i d v i s i t p l u s ( P l u s node ) { 14 v i s i t b i n a r y ( node, + ) ; 15 } / 99

20 Statische Programmanalyse: Traversierungen von ASTs Attributgrammatiken Probleme des Visitor-Musters: Visitor ist programmatisch und erfordert viel Kodieraufwand Visitor reicht nur für einfache Aufgaben aus Attributgrammatiken für den Syntaxbaum: beschreiben Berechnung von Knotenattributen Berechnung ist deklarativ Traversierungsreihenfolge ergibt sich aus Berechnungsvorschrift automatische Code-Generierung ist möglich 38 / 99 Statische Programmanalyse: Traversierungen von ASTs Attributgrammatiken Definition Eine Attributgrammatik besteht aus: Beispiel: Attributen für Grammatiksymbole (Nichtterminal und Terminal) bzw. Baumknoten deklarativen Regeln zur Berechnung der Attribute 1 e x p r r e t u r n s [ Expr t r e e ] : 2 t=term o= + e=e x p r { $ t r e e = new P l u s ( $t. t r e e, $e. t r e e ) ; } 3 t=term o= e=e x p r { $ t r e e = new Minus ( $t. t r e e, $e. t r e e ) ; } 4 t=term { $ t r e e = $t. t r e e ; } 5 ; 39 / 99

21 Statische Programmanalyse: Traversierungen von ASTs Arten von Attributen Definition Ein Attribut eines Nichtterminals ist synthetisiert, wenn es nur von Attributen von Symbolen der rechten Seite seiner Regeln abhängt. 1 e x p r r e t u r n s [ Expr t r e e ] : 2 t=term o= + e=e x p r { $ t r e e = new P l u s ( $t. t r e e, $e. t r e e ) ; } 3 t=term o= e=e x p r { $ t r e e = new Minus ( $t. t r e e, $e. t r e e ) ; } 4 t=term { $ t r e e = $t. t r e e ; } 5 ; 40 / 99 Statische Programmanalyse: Traversierungen von ASTs Arten von Attributen Definition Ein Attribut eines Nichtterminals ist ererbt, wenn es nur von Attributen von Symbolen der linken Seite und von Geschwistersymbolen der Regeln abhängt, in denen das Symbol auf einer rechten Seite auftritt. Ein Geschwistersymbol ist ein Symbol, das auf der selben rechten Seite auftritt. 41 / 99

22 Statische Programmanalyse: Traversierungen von ASTs Arten von Attributen 1 e x p r r e t u r n s [ Expr t r e e ] 2 : t=term e=e x p r c o n t i n u e d [ $t. t r e e ] { $ t r e e = $e. t r e e ; } 3 ; 4 5 e x p r c o n t i n u e d [ Expr i n h ] r e t u r n s [ Expr t r e e ] 6 : o= + 7 t=term 8 e=e x p r c o n t i n u e d 9 [ new P l u s ( $o. l i n e, $o. column, $inh, $t. t r e e ) ] 10 { $ t r e e = $e. t r e e ; } 11 o= 12 t=term 13 e=e x p r c o n t i n u e d 14 [ new Minus ( $o. l i n e, $o. column, $inh, $t. t r e e ) ] 15 { $ t r e e = $e. t r e e ; } 16 { $ t r e e = $ i n h ; } 17 ; 42 / 99 Statische Programmanalyse: Traversierungen von ASTs Datenfluss zwischen Attributen expr tree term tree expr_continued inh tree + term expr_continued tree inh tree term expr_continued tree ɛ inh tree 43 / 99

23 Statische Programmanalyse: Quellennahe Repräsentation Anforderungen an Zwischendarstellungen möglichst quellennah möglichst vereinheitlicht 44 / 99 widersprüchliche Anforderungen: 1. möglichst quellennah, da Informationen an Wartungsprogrammierer ausgegeben werden sollen bzw. tatsächlicher Code wieder generiert werden soll alle spezifischen Konstrukte müssen dargestellt werden 2. möglichst vereinheitlicht, um das Schreiben von Programmanalysen für verschiedene Programmiersprachen zu vereinfachen möglichst wenige, allgemeine Konstrukte

24 Statische Programmanalyse: Quellennahe Repräsentation Quellennahe Betrachtung while P loop A; end loop; cond P while A body 45 / 99 Statische Programmanalyse: Quellennahe Repräsentation Einfache allgemeine Konstrukte while P loop A; end loop; ist äquivalent zu: loop if P then A; else exit; end if; end loop; P loop body then if cond else A exit 46 / 99

25 Statische Programmanalyse: Quellennahe Repräsentation Vereinigung der Sichten P loop body then if cond else A exit cond P while A body inheritance hierarchy: loop is a for while is a loop real body cond while body A then P cond if else exit syntaktische Kante Annotation 47 / 99 Statische Programmanalyse: Kontrollfluss Kontrollflussinformation main entry intraprozedural: Flussgraph Knoten: Grundblöcke Kanten: (bedingter/unbedingter) Kontrollfluss interprozedural: Aufrufgraph Multigraph Knoten: Prozeduren Kanten: Aufruf (eine für jede Aufrufstelle); Schleifen Rekursion t a = 1; b = 2; a>0 f exit main c = f(c); f 49 / 99

26 Intraprozeduraler Kontrollfluss ergibt sich aus syntaktischer Struktur und etwaigen Gotos, Exits, Continues etc.interprozeduraler Kontrollfluss ergibt sich aus expliziten Aufrufen im Programmcode sowie aus Aufrufen über Funktionszeiger Statische Programmanalyse: Kontrollfluss Intra- und interprozeduraler Kontrollfluss main int f (int p) entry entry t a>0 f c p r = 0; x = p; a = 1; b = 2; c = f(c); f x>0 exit r c t r = r + p; x = x - 1; exit & return r 50 / 99

27 Statische Programmanalyse: Kontrollfluss Fragestellungen zum Kontrollfluss Was wird garantiert vorher ausgeführt? Was wird garantiert nachher ausgeführt? 51 / 99 Fragestellungen: Welche Prozeduren sind lokal zueinander? Genauer: Gibt es eine Prozedur D, über nur die ein Aufruf von N erfolgt? Welcher Block D im Flussgraph muss in jedem Falle passiert werden, damit Block N ausgeführt werden kann? Antwort: D ist der Dominator von N

28 Statische Programmanalyse: Kontrollfluss Dominanz Definition Ein Knoten D dominiert einen Knoten N (D dom N), wenn D auf allen Pfaden vom Startknoten zu N liegt. Ein Knoten D dominiert N strikt, wenn D dom N D N. Ein Knoten D ist der direkte Dominator von N (idom(n)=d), wenn 1 D ist ein strikter Dominator von N: D dom N (D N) und 2 alle weiteren Dominatoren von N dominieren D: D dom N : (D dom D D = D) 52 / 99 Statische Programmanalyse: Kontrollfluss Dominanz Graph Dominanzbaum / 99

29 Statische Programmanalyse: Kontrollfluss Postdominanz Definition Ein Knoten D postdominiert einen Knoten N, wenn jeder Pfad von N zum Endknoten den Knoten D enthält (entspricht Dominanz des umgekehrten Graphen). Graph 1 Postdominanzbaum 2 3 exit exit / 99 Statische Programmanalyse: Kontrollabhängigkeit Kontrollabhängigkeit Definition Knoten X ist kontrollabhängig von Bedingung B, wenn B entscheiden kann, ob X ausgeführt wird: 1 B muss mehrere direkte Nachfolger haben und 2 B hat einen Pfad zum Endknoten, der X vermeidet (d.h. B kann nicht von X postdominiert werden) und 3 B hat einen Pfad zu X, d.h. insgesamt hat B mindestens zwei Pfade: einer führt zu X einer umgeht X 55 / 99

30 Statische Programmanalyse: Kontrollabhängigkeit Kontrollabhängigkeit Definition Ein Knoten X ist direkt kontrollabhängig von einem Knoten B genau dann, wenn 1 es einen nicht-leeren Pfad von B nach X gibt, so dass X jeden Knoten auf dem Pfad (ohne B) postdominiert und 2 entweder X = B oder X postdominiert B nicht B a X für alle a: X postdominiert a B=X a für alle a: X postdominiert a exit exit transitiver Kontrollfluss 56 / 99 Statische Programmanalyse: Kontrollabhängigkeit Kontrollabhängigkeit Definition Ein Knoten X ist direkt kontrollabhängig von einer Kante (B, S) genau dann, wenn 1 es einen nicht-leeren Pfad beginnend mit (B, S) nach X gibt, so dass X jeden Knoten auf dem Pfad (ohne B) postdominiert und 2 entweder X = B oder X postdominiert B nicht B S X B=X a a S für alle a: X postdominiert a für alle a: X postdominiert a exit exit transitiver Kontrollfluss direkter Kontrollfluss 57 / 99

31 Statische Programmanalyse: Kontrollabhängigkeit Kontrollabhängigkeit 1 f u n c t i o n CD ( (B, S ) : Edge ) r e t u r n s e t o f nodes 2 b e g i n c o n t r o l dependency 3 4 depends := ; 5 X := S ; 6 7 w h i l e X pdom (B) l o o p 8 depends := depends {X } ; 9 X := pdom (X ) ; 10 end l o o p ; r e t u r n depends ; 13 end CD; 58 / 99 Statische Programmanalyse: Kontrollabhängigkeit Kontrollabhängigkeit Beispiel für Kontrollabhängigkeit KFG if (b1) { do { a; } while (b2); } f b1 t a b2 f exit t Postdominanz exit b1 b2 a (b1, a) (b1, exit) (b2, a) (b2, exit) 59 / 99

32 (b1, a) a, b2 (b1, exit) (b2, a) a, b2 (b2, exit) Statische Programmanalyse: Kontrollabhängigkeit Kontrollabhängigkeit Für strukturierte Programme: eine Anweisung ist kontrollabhängig von der Bedingung der nächstumgebenden Schleife oder bedingten Anweisung. 1 w h i l e ( a ) { 2 i f ( b ) { 3 x = y ; // k o n t r o l l a b h ä n g i g von b 4 } 5 z = 1 ; // k o n t r o l l a b h ä n g i g von a 6 do { 7 z = z + 1 ; 8 } 9 w h i l e ( z < 10) 10 } 60 / 99

33 N.B.: Bedingungen in repeat-schleifen sind von sich und dem umgebenden Konstrukt abhängig (siehe voriges Beispiel). Statische Programmanalyse: Kontrollabhängigkeit Repräsentation der Kontrollabhängigkeit b1 t t f t t a t t b2 f exit 61 / 99

34 Statische Programmanalyse: Datenabhängigkeit Datenabhängigkeiten Datenflussrelevante Operationen: Set = Setzen eines Wertes Use = Verwendung eines Wertes Datenabhängigkeiten Set-Use (Datenabhängigkeit) Use-Set (Anti-Dependency) Set-Set (Output-Dependency) 63 / 99 Set-Use Beziehung (Datenabhängigkeit) A setzt den Wert, der von B verwendet wird Use-Set Beziehung (Anti-Dependency) A liest den Wert und B überschreibt ihn danach Set-Set Beziehung (Output-Dependency) der von A gesetzte Wert wird von B überschrieben Codetransformationen müssen diese Beziehungen erhalten.

35 Statische Programmanalyse: Datenabhängigkeit Datenabhängigkeit (Set-Use) a := 10; b := a + 1; a := 2 * a; c := a + b; 64 / 99 Wichtigste Beziehung: Set-Use Zwischen der 2. und 3. Anweisung besteht eine Use-Set, zwischen der 1. und 3. Anweisung eine Set-Set -Beziehung.

36 Statische Programmanalyse: Datenflussanalyse: Bestimmung von Set Datenflussprobleme Gültige Definitionen (Reaching Definitions)... beantwortet die Frage, welche Definition einer Variablen (d.h. Zuweisungen an diese Variable) welche Verwendungen der selben Variablen erreichen. Definition Eine Definition D erreicht einen Punkt P, falls es einen Weg von D nach P gibt, auf dem keine weitere Zuweisung an die in D gesetzte Variable V erfolgt. 65 / 99 Statische Programmanalyse: Datenflussanalyse: Bestimmung von Set Beispielprogramm 1 v o i d printsum ( f l o a t a [ ] ) { 2 i n t i ; 3 f l o a t s ; 4 f l o a t v ; 5 6 i = 0 ; 7 s = 0. 0 ; 8 v = 0. 0 ; 9 10 w h i l e ( i < a. l e n g t h ) { 11 v = a [ i ] ; 12 i = i + 1 ; 13 s = s + v ; 14 } p r i n t ( sum, s ) ; 17 } 66 / 99

37 Statische Programmanalyse: Datenflussanalyse: Bestimmung von Set Grundlage Kontrollflussgraph B0 entry B1 6: i = 0 7: s = 0.0 8: v = 0.0 B2 B4 10: i < a.length 16: print("sum", s) f t B3 11: v = a[i] 12: i = i : s = s + v B5 exit 67 / 99 Statische Programmanalyse: Datenflussanalyse: Bestimmung von Set Zuweisungen im Kontrollflussgraph I. Allg.: Konservative Annahme: Jeder Aufruf einer unbekannten Methode liest und ändert alle Referenzparameter sowie das betroffene Objekt und liest alle Werteparameter. Im Beispiel: Anweisung zugewiesene Variablen (Set) gelesene Variablen (Use) 6 i 7 s 8 v 10 i, a 11 v i, a 12 i i 13 s s, v 16 s 68 / 99

38 Statische Programmanalyse: Datenflussanalyse: Bestimmung von Set Lokale Datenflussanalyse Lokale Information pro Grundblock B: GEN(B) = Menge aller Zuweisungen in B, die das Ende von B erreichen (lokale Analyse im Grundblock). KILL(B) = Menge aller Zuweisungen im gesamten Kontrollflussgraphen (KFG), deren Variable in B neu gesetzt wird und nicht in GEN(B) enthalten ist (flussinsensitive Analyse im KFG). Im Beispiel: Block GEN KILL B0 B1 6,7,8 11,12,13 B2 B3 11,12,13 6,7,8 B4 B5 69 / 99 Statische Programmanalyse: Datenflussanalyse: Bestimmung von Set Globale Datenflussanalyse über Kontrollflussgraph Grundblock hängt von seinen Vorgängern ab: in(b) = Definitionen, die den Eingang von B erreichen out(b) = Definitionen, die den Ausgang von B erreichen Datenflussgleichungen: in(b) = B ist Vorgänger von B out(b ) out(b) = (in(b) KILL(B)) GEN(B) 70 / 99

39 rekursives Problem gesucht ist der kleinste Fixpunkt Statische Programmanalyse: Datenflussanalyse: Bestimmung von Set Iterative Lösung der Gleichungen 1 f o r each b l o c k B l o o p 2 out (B) := GEN(B ) ; 3 end l o o p ; 4 5 s t a b l e := f a l s e ; 6 w h i l e s t a b l e l o o p 7 s t a b l e := t r u e ; 8 f o r each b l o c k B l o o p 9 i n (B) := B B out(b ) ; 10 o l d o u t := out (B ) ; 11 out (B) := ( i n (B) KILL (B) ) GEN(B ) ; 12 i f out (B) o l d o u t then 13 s t a b l e := f a l s e ; 14 end i f ; 15 end l o o p ; 16 end l o o p ; 71 / 99

40 Statische Programmanalyse: Datenflussanalyse: Bestimmung von Set Iterative Lösung der Gleichungen mit Worklist N = Menge aller Grundblöcke im Kontrollflussgraph 1 f o r each b l o c k B l o o p 2 out (B) := GEN(B ) ; 3 end l o o p ; 4 wl := N {entry} ; 5 6 l o o p 7 B := f i r s t ( wl ) ; 8 wl := wl {B} ; 9 e f f e c t := ; 10 f o r each P P r e d e c e s s o r s (B) l o o p 11 e f f e c t := e f f e c t out (P ) ; 12 end l o o p ; 13 i f i n (B) e f f e c t then 14 i n (B) := e f f e c t ; 15 out (B) := ( i n (B) KILL (B) ) GEN(B ) ; 16 wl := wl S u c c e s s o r s (B ) ; 17 end i f ; 18 e x i t when wl = ; 19 end l o o p ; 72 / 99 Statische Programmanalyse: Datenflussanalyse: Bestimmung von Set Beispiel B wl B1 B2 B3 B4 gen kill gen kill gen kill gen kill in out in out in out in out B1,B2,B3,B / 99

41 Beispiel für Worklist-Algorithmus B wl B1 B2 B3 gen kill gen kill gen kill gen in out in out in out in B1,B2,B3,B B1 B1,B2,B3,B B2 B2,B3,B , , B3 B3,B , , , B4 B4,B , , , ,11-13 B2 B , , , ,11-13 Statische Programmanalyse: Datenflussanalyse: Bestimmung von Set Terminierung des Algorithmus Der Algorithmus terminiert, weil wenn keine Menge mehr wächst, ist Abbruchbedingung erfüllt ansonsten: eine Menge wird größer die Mengen wachsen monoton die Mengen sind nach oben begrenzt (durch alle Definitionen der Methode) und können nicht beliebig wachsen 74 / 99

42 Statische Programmanalyse: Static Single Assignment Form Repräsentation der Datenabhängigkeit x < 0 a := 1; y > 0 a := 2; a := 2; z < y... := a;... := a;... := a; 75 / 99 Statische Programmanalyse: Static Single Assignment Form Repräsentation der Datenabhängigkeit Definition Ein Programm ist in der Static Single Assignment Form (SSA), wenn jede Variablenverwendung (Use) nur eine Definition (Set) hat. 76 / 99

43 Wunsch nach einer kompakteren Darstellung: Nur eine Definition für jede Verwendung. Wird erreicht durch eingeführte künstliche Zuweisungen, sogenannte φ-knoten: am Anfang der Grundblöcke, an denen Kontrollflüsse zusammenlaufen, auf denen verschiedene Definitionen der gleichen Variablen liegen. Statische Programmanalyse: Static Single Assignment Form Static Single Assignment Form x < 0 a := 1; y > 0 a := 2; a := 2; a := φ(a,a) z < y a := φ(a,a)... := a;... := a;... := a; 77 / 99

44 Statische Programmanalyse: Static Single Assignment Form Beispiel der SSA 1 x, y, z : T; x 0 := i n i t ; y 0 := i n i t ; z 0 := i n i t ; 2 i f cond1 then 3 y 1 := 4 ; 4 x 1 := 5 ; 5 e l s e 6 y 2 := 3 ; 7 end i f ; 8 x 2 := φ( x 0, x 1 ) ; y 3 := φ( y 1, y 2 ) ; 9 w h i l e z 1 := φ( z 0, z 5 ) ; cond2 l o o p 10 i f y 3 > 0 then 11 z 2 := x 2 + z 1 ; 12 end i f ; 13 z 3 := φ( z 1, z 2 ) 14 i f y 3 <= 0 then 15 z 4 := y 3 ; 16 end i f ; 17 z 5 := φ( z 3, z 4 ) 18 end l o o p ; = z 1 ; 78 / 99 Statische Programmanalyse: Static Single Assignment Form Beispielanwendung Problem: Finde alle potenziell lokal uninitialisierten Variablen Lösung mit SSA: für jede initiale Definition D: propagiere D längs der Use-Kanten und markiere alle dabei erreichten Verwendungen von Variablen jede markierte Verwendung einer Variablen ist potenziell undefiniert 79 / 99

45 Statische Programmanalyse: Static Single Assignment Form Einfügepunkte für φ-knoten φ-knoten werden eingefügt... am Anfang der Grundblöcke, an denen Kontrollflüsse zusammenlaufen, auf denen verschiedene Definitionen der gleichen Variablen liegen. Wie lassen sich diese Punkte effizient algorithmisch bestimmen? 81 / 99 Statische Programmanalyse: Static Single Assignment Form Einfügepunkte für φ-knoten (Cytron u. a. 1991) entry 1: a = init b 2: a = : a = 2 b b dom c 1 c 1 b dom c 2 c 2 c 1 b dom c 1 c 1, b Dominanzgrenzen({entry, b, b }) 82 / 99

46 Statische Programmanalyse: Static Single Assignment Form Dominanzgrenzen Definition Die Dominanzgrenze (engl. Dominance Frontier) DF (B) eines Blocks B ist die Menge aller Blöcke C wie folgt: 1 B dom C C ist unmittelbarer Vorgänger von C im Kontrollflussgraph und 2 entweder B = C oder B dom C (d.h. B ist kein strikter Dominator von C) 83 / 99 Anschaulich: Dominanzgrenze enthält alle Blöcke, die aus dem Dominanzteilbaum mit der Wurzel B (exklusive B selbst) heraus führen.

47 Statische Programmanalyse: Static Single Assignment Form Dominanzgrenzen b0 b0 b1 b2 b3 b5 b4 b3 b2 b1 b4 b5 b6 b0 b1 b2 b3 b4 b5 b6 DF b1, b6 b2, b5 b2, b5 b3 b1, b6 b6 dom control 84 / 99 Statische Programmanalyse: Static Single Assignment Form SSA-Aufbau 1 f o r V Variables l o o p 2 wl := {B B contains Set(V )} {entry} 3 done := 4 w h i l e wl l o o p 5 s e l e c t any B wl 6 wl := wl {B} 7 f o r B DF (B) l o o p 8 i f B done then 9 n := #p r e d e c e s s o r s (B ) 10 i n s e r t V φ(v,..., V ) i n t o B with n arguments 11 wl := wl { B } 12 end i f 13 end l o o p 14 done := done { B } 15 end l o o p 16 end l o o p 85 / 99

48 für jedes Set(V) in einem Block B müssen φ-knoten in allen Blöcken B DF (B) eingefügt werden φ-knoten sind auch Zuweisungen Statische Programmanalyse: Static Single Assignment Form Varianten von Set Sicherheit der Überschreibung: Starke Aktualisierung (must-set): v = 1; Schwache Aktualisierung (may-set): p = &v; if (foo()) p = &w; *p = 1; Umfang der Überschreibung: Vollständige Aktualisierung: v = 1; Teilweise Aktualisierung: a[i] = 1; 86 / 99

49 Statische Programmanalyse: Static Single Assignment Form Wichtige Mengen beim Aufbau von SSA Anweisung A: Must-Set (A) May-Set (A) May-Use (A) 1 a 1 = 1 ; // Must Set ( 1 ) = { a } 2 f (&a ) ; // May Set ( 2 ) = { a }, May Use ( 2 ) = { a } 3 a 2 = φ(a 1, a f ) // a f r e p r ä s e n t i e r t den Wert aus f 4... a 2... // May Use ( 4 ) = { a } 87 / 99 Must-Set (A): Menge von Variablen, die sicher von A verändert werden identifiziert die Definitionen May-Set (A): Menge von Variablen, die möglicherweise von A verändert werden hier muss ein φ-knoten eingefügt werden, um schwache Aktualisierung zu repräsentieren May-Use (A): Menge von Variablen, die möglicherweise von A verwendet werden bei allen Verwendungen müssen Verweise auf Definition eingetragen werden N.B.: May-Set und Must-Set sind disjunkt.

50 Statische Programmanalyse: Aliasing Probleme beim Aufbau von SSA 1 a := 1 ; 2 b := 2 ; 3 c := a + b ; 88 / 99 Was ist der Wert von c?

51 Statische Programmanalyse: Aliasing Probleme beim Aufbau von SSA Definition Aliasing: Zwei Namen sind Aliase, wenn sie auf überlappende Speicherbereiche verweisen. 1 y := 5 ; 2 3 i f... then 4 x := 6 ; 5 end i f ; = y ; 1 y := 5 ; 2 3 i f... then 4 x := 6 ; i f I s A l i a s ( x, y ) then y := x ; end i f ; 5 end i f ; = y ; 1 y := 5 ; 2 3 i f... then 4 x := 6 ; i f I s A l i a s ( x, y ) then y := x ; end i f ; 5 end i f ; 6. Problem:.. y := φ( y, y ) ; 7. x..:= =...; y ; falls Alias(x,y), dann ist Zuweisung an x auch Zuweisung an y 1 1 := 5 ; 2 3 i f... then 4 x 1 := 6 ; i f I s A l i a s ( x, y ) then y 2 := x 1 ; end i f ; 5 end i f ; 6... y 3 := φ( y 1, y 2 ) ; 7... = y 3 ; 89 / 99

52 Statische Programmanalyse: Aliasing Aliasing-Varianten parameter-induziertes Aliasing durch Referenzparameter p (x, x) (bzw. p(&x, &x) in C und C++) p (g), wobei g eine globalere Variable ist und in p verwendet wird Arraykomponenten a [2 * i] und a [ j ] 90 / 99 parameter-induziertes Aliasing durch Referenzparameter Lösung: Propagierung der Alias-Info über den Call-Graphen (Ansonsten konservative Annahme: zwei Referenzparameter bzw. globale Variable/Referenzparameter sind Aliase; eventuell kann Typinformation helfen) Arraykomponenten Lösungsansatz: Löse Gleichung 2*i = j Ansonsten: Modelliere Zuweisungen an Teilkomponente als Zuweisung an gesamtes Array: Partial Update/Read m.a.w. konservative Annahme, dass jeder Index sich auf alle Array-Elemente beziehen kann.

53 Statische Programmanalyse: Aliasing Aliasing-Varianten stack-gerichtete Zeiger p := &x; heap-gerichtete Zeiger p := new T; q := new T; q.next = p; 91 / 99 stack-gerichtete Zeiger Lösungsansatz: Points-To-Analyse Konservative Annahme: *p könnte jede statische Variable betreffen, deren Adresse genommen wird. heap-gerichtete Zeiger Lösungsansatz: Shape-Analyse Konservative Annahme: *p kann jedes Element des Heaps betreffen.

54 Statische Programmanalyse: Aliasing Probleme beim Aufbau von SSA Aufrufe von Unterprogrammen (Staiger u. a. 2007b, a) 1 x := 1 ; 2 f ( a, b ) ; 3 h a t x noch den Wert 1? 92 / 99 Welchen äußeren Effekt haben Unterprogrammaufrufe? Lösung: Globale Analysen auf Seiteneffekte (aber: Problem von Bibliotheksroutinen, deren Quell-Code nicht vorhanden ist) Ansonsten konservative Annahme: Aufruf eines Unterprogramms U verändert alle globalen Variablen (nicht nur jene im Sichtbarkeitsbereich von U) sowie jeden Referenzparameter optimistische Annahme:... verändert nur seine Referenzparameter und über sie erreichbare Variable

55 Statische Programmanalyse: Analysemöglichkeiten Phasenspezifische Analysen (Abstraktionsebenen) I Programmtext mit Makros Suche nach Zeichenketten (einschließlich Makros) Programmtext nach Makro-Expansion Suche nach Zeichenketten (ohne Makros) Token-Strom Zeichenketten sind klassifiziert Suche nach Tokens abstrakter Syntaxbaum gibt syntaktische Dekomposition wieder Suche nach syntaktischen Mustern; evtl. auch spezialisierte Attributberechnungen 93 / 99 Statische Programmanalyse: Analysemöglichkeiten Phasenspezifische Analysen (Abstraktionsebenen) II attributierter abstrakter Syntaxbaum Namensbindung und Typinformation verfügbar Cross-Reference-Information Suche nach spezifischen Variablen möglich Kontroll- und Datenflussinformation Kontrollflussgraph Aufrufgraph explizit Aufrufe über Funktionszeiger Explizite Darstellung von Datenabhängigkeiten Alias-Information Points-To-Information 94 / 99

56 Statische Programmanalyse: Wiederholungsfragen Wiederholungs- und Vertiefungsfragen I Warum normalisiert gcc viele Anweisungen des Quellcodes? Warum sind diese Art Modifikationen für RE nicht wünschenswert? Wie kann man Quellennähe erreichen? Was ist ein abstrakter Syntaxbaum? Gegeben ist die folgende Grammatik... Geben Sie hierfür eine abstrakte Syntax an. Wie erreicht man sowohl Quellennähe als auch Vereinheitlichung? Selbe Frage mit konkretem Beispiel für Case-Anweisung in der Programmiersprachen Ada mittels if-anweisung. Funktioniert die Umsetzung analog für C-Switch? Abstrakter Syntaxbaum gibt nur syntaktische Dekomposition wieder. Wie kann Kontrollfluss explizit dargestellt werden? 95 / 99 Statische Programmanalyse: Wiederholungsfragen Wiederholungs- und Vertiefungsfragen II Wie ergibt sich Kontrollabhängigkeit aus dem Flussgraphen (grob skizziert)? Lässt sich Kontrollflussabhängigkeit auch direkt aus der Syntax ermitteln? Wie können Datenabhängigkeiten explizit repräsentiert werden? Datenabhängigkeitskanten (SSA) Welche Eigenschaft hat die SSA? Wie wird diese Eigenschaft erreicht? Wo werden φ-knoten eingefügt? Welche weiteren Datenabhängigkeiten gibt es? Warum sind diese Abhängigkeiten für das RE überhaupt interessant? Wo werden Set / Use und Kontrollabhängigkeiten im RE noch benutzt? 96 / 99

57 Statische Programmanalyse: Wiederholungsfragen Literatur Muchnick (1997): gutes Lehrbuch zu Compilerbau Morgan (1998): Zwischendarstellungen sowie Kontroll- und Datenflussanalysen; enthält eine bessere Beschreibung der SSA als Muchnick (1997) Koschke u. a. (1998): Zwischendarstellung für das Reverse Engineering und dessen spezielle Anforderungen Plödereder (2008): Folien, Skript und Übungen zur Vorlesung Programmanalysen und Compilerbau an der Universität Stuttgart Staiger u. a. (2007b, a): interprozedurale SSA-Form 97 / 99 Statische Programmanalyse: Wiederholungsfragen 1 Cytron u. a Cytron, Ron ; Ferrante, Jeanne ; Rosen, Barry K. ; Wegman, Mark N. ; Zadeck, F. K.: Efficiently Computing Static Single Assignment Form and the Control Dependence Graph. In: ACM Transactions on Programming Languages and Systems 13 (1991), Oktober, Nr. 4, S Koschke u. a Koschke, Rainer ; Girard, Jean-François ; Würthner, Martin: An Intermediate Representation for Reverse Engineering Analyses. In: Proceedings of the 5th Proceedings of the Working Conference on Reverse Engineering. Honolulu, HI, USA : IEEE Computer Society Press, Oktober 1998, S Morgan 1998 Morgan, Robert: Building an Optimizing Compiler. Digital Press, Muchnick 1997 Muchnick, Steven S.: Advanced Compiler Design and Implementation. Morgan Kaufmann, / 99

58 Statische Programmanalyse: Wiederholungsfragen 5 Plödereder 2008 Plödereder, Erhard: Vorlesung Programmanalysen und Compilerbau. Vorlesungsskriptum. Oktober URL Programmanalysen/skript-CB+ProgAn-08.pdf 6 Staiger u. a. 2007a Staiger, Stefan ; Vogel, Gunther ; Keul, Steffen ; Wiebe, Eduard: Interprocedural Static Single Assignment Form. In: Proceedings of the Working Conference on Reverse Engineering, IEEE Computer Society Press, Oktober 2007, S URL freeabs_all.jsp?arnumber= Staiger u. a. 2007b Staiger, Stefan ; Vogel, Gunther ; Keul, Steffen ; Wiebe, Eduard: Interprocedural Static Single Assignment Form in Bauhaus / Institut für Softwaretechnologie, Abteilung Programmiersprachen. Universität Stuttgart, November Forschungsbericht. URL http: //elib.uni-stuttgart.de/opus/volltexte/2007/3338/ 99 / 99