Download Analyzing and Understanding Software - Slide Notes | CMSC 631 and more Study notes Computer Science in PDF only on Docsity!
CMSC 631 ā Program Analysis and Understanding Spring 2006
CMSC 631, Fall 2004 (^2)
ā¢ Topic: Analyzing and understanding software
ā¢ Three main focus areas:
ā Static analysis
- Automatic reasoning about source code ā (^) Formal systems and notations
- Vocabulary for talking about programs ā Programming language features
- Affects programs and how we reason about them
About this Class
CMSC 631, Fall 2004 (^3)
ā¢ Jeff Foster
ā (^) Office: 4129 AVW ā (^) E-mail: jfoster at cs.umd.edu ā Office hours: M 1-2pm, Tu 11am-12pm
Personnel
CMSC 631, Fall 2004 (^4)
ā¢ CMSC 430 or equivalent compiler class
ā (^) Ideas we will use in this class:
- Parse trees/abstract syntax trees
- BNF notation for grammars
- Type checking (usually not much covered in compilers class)
- Data flow analysis (sometimes not covered in compilers class)
- Tools like yacc and lex may be useful for your project ā (^) We wonāt use most of the other material
- So even if you havenāt taken compilers class, you may be OK
- Talk to me if youāre not sure
Prerequisite
CMSC 631, Fall 2004 (^5)
Textbooks
ā¢ No required textbooks
ā¢ Two recommended texts
ā Pierce, Types and Programming Languages ā (^) Huth and Ryan, Logic in Computer Science
ā¢ Neither covers everything in the course
ā¢ On reserve in CS library
CMSC 631, Fall 2004
Forum
ā¢ Web forum on CS dept server
ā (^) https://forum.cs.umd.edu/forumdisplay.php?f=
ā¢ Can use the forum to communicate with others
in the class and ask questions of general interest
6
CMSC 631, Fall 2004 (^7)
Expectations: Homework
ā¢ Two kinds of assignments:
ā (^) Programming assignments (20% of grade)
- Every two weeks
- Implement the ideas we see in lecture ā (^) Written assignments (10% of grade)
- Every week
- Short problem sets
ā¢ This is how you will learn things
ā (^) Much more effective than listening to a lecture CMSC 631, Fall 2004 (^8)
Late Policy on Assignments
ā¢ Programming Assignments: Due at midnight
ā¢ Written assignments: Due at beginning of class
ā (^) No late submissions
ā¢ Contact me about extenuating circumstances
ā E.g., religious holidays ā Inform me as soon as possible
CMSC 631, Fall 2004 (^9)
ā¢ Will need to read some papers for class
ā (^) More later on in the semester ā (^) Should come prepared to contribute to discussion
ā¢ Student presentations later in the semester
ā Read 1-2 papers on a topic ā Present a lecture in class about the material
ā¢ 10% of grade on class participation
Expectations: Participation
CMSC 631, Fall 2004 (^10)
ā¢ Class goal: Teach you how to do research
ā (^) So you have to do research as part of the class
ā¢ Substantial research project (35% of grade)
ā Any topic vaguely related to the class is acceptable
- Will post some suggestions for projects later on
- May also be able to share project with other class ā Completed in groups of size 1 or 2
ā¢ This will consume second-half of semester
ā (^) Will ease up on homeworks, reading
Expectations: Project
Expectations: Project (contād)
ā¢ Deliverables
ā Project proposal (one page) + talk with me ā Project write-up
- A conference-style paper (5-15 pages, as appropriate) ā (^) Implementation, if any ā In-class presentation
- 15-20 minutes, depending on # of projects
ā¢ Final exam (25% of grade)
ā (^) Based on written and programming assignments ā Take-home or in-class (weāll vote at the end of the semester)
Expectations: Exam
CMSC 631, Fall 2004 (^19)
Control-Flow Graph
x := 3
y := z + w y := 0
x := 2 * x
x = *
x = 3
x = 3
x = 3
x = 3
x = 6
x =?
x =?
x =?
CMSC 631, Fall 2004 (^20)
ā¢ Dataflow facts form a lattice
ā¢ Each statement has a transformation function
ā (^) Out(S) = Gen(S) U (In(S) - Kill(S))
ā¢ Terminates because
ā (^) Finite height lattice ā (^) Monotone transformation functions
Lattices and Termination
x =? x = 3 x = 6 ...
x = *
CMSC 631, Fall 2004 (^21)
ā¢ Transform CFG so each use has a single defn
Static Single Assignment Form
x := 0
v := 3 v := 4 + x
x := x + v
x 1 := 0
v 1 := 3 v 2 := 4 + x 1
v 3 := Ī¦(v 1 ,v 2 )
x 2 := x 1 + v 3
CMSC 631, Fall 2004 (^22)
ā¢ Three syntactic forms
variable function function application
ā¢ One reduction rule
ā (^) (replace by in )
ā¢ Can represent any computable function!
Lambda Calculus
ā¢ Conditionals
ā (^) true = false = ā if a then b else c =
- if true then b else c =
- if false then b else c =
ā¢ Can also represent numbers, pairs, data
structures, etc, etc.
ā¢ Result: Lingua franca of PL
Example
ML: Meta-Language
ā¢ ML designed originally for theorem provers
ā (^) But after a while, realized could be general-purpose
ā¢ Mostly-functional language
ā Similar to lambda-calculus
- Mostly functional, encouraged not to use side-effects
- Call-by-value
ā¢ Weāll use OCaml for programming assignments
CMSC 631, Fall 2004 (^25)
ā¢ Machine represents all values as bit patterns
ā (^) Is 00110110111100101100111010101000
- A signed integer? Unsigned integer? Floating-point number? Address of an integer? Address of a function? etc.
ā¢ Type systems allow us to distinguish these
ā To choose operation (which + op), e.g., FORTRAN ā To avoid programming mistakes
- E.g., donāt treat integer as a function address
Type Systems
CMSC 631, Fall 2004 (^26)
in type environment , expression has type
Simply-typed Ī»-calculus
dom(A) !
!
!
!
!! !
!
CMSC 631, Fall 2004 (^27)
ā¢ Liskov:
ā If for each object of type there is an object of type such that for all programs defined in terms of , the behavior of is unchanged when is substituted for then is a subtype of.
ā¢ Informal statement
ā If anyone expecting a can be given an instead, then is a subtype of.
Subtyping
CMSC 631, Fall 2004 (^28)
ā¢ Old idea: Shouldnāt just hack up code, try to
prove programs are correct
ā¢ Proofs require reasoning about the meaning of
programs
ā¢ First system: Formalize program behavior in logic
ā Hoare, Dijkstra, Gries, others
Axiomatic Semantics
ā (^) If statement is executed in a state satisfying precondition , then will terminate, and will hold of the resulting state ā Partial correctness: ignore termination
ā¢ Weakest precondition for assignment
ā (^) Axiom: ā (^) Example:
Hoare Triples
ā¢ Technique for validating hardware
ā (^) Lots of parallelism (concurrency), but ā Not a lot of structure (e.g., no dynamic allocation)
ā¢ Example: mutual-exclusion protocol
Model Checking
loop out: x1 := 1; last := 1 req: await x2 = 0 or last = 2 in: x1 := 0 end loop
loop out: x2 := 1; last := 2 req: await x1 = 0 or last = 1 in: x2 := 0 end loop (Example from Henzinger)
||
CMSC 631, Fall 2004 (^37)
ā¢ SLAM and BLAST
ā (^) Focus on device drivers: lock/unlock protocol errors, and other errors sequencing of operations
ā¢ Uses alias analysis, predicate abstraction, and
more
Applications: Model Checking
CMSC 631, Fall 2004 (^38)
ā¢ Extended Static Checker
ā (^) Can perform deep reasoning about programs ā (^) Array out-of-bounds ā (^) Null pointer errors ā Failure to satisfy internal invariants
ā¢ Based on theorem proving
Applications: Axiomatic Semantics
ā¢ Type qualifiers
ā (^) Format-string vulnerabilities, deadlocks, file I/O protocol errors, kernel security holes
ā¢ Vault and Cyclone
ā Memory allocation and deallocation errors, library protocol errors, misuse of locks
Applications: Type Systems
ā¢ PL has a great mix of theory and practice
ā (^) Very deep theory ā (^) But lots of practical applications
ā¢ Recent exciting new developments
ā Focus on program correctness instead of speed ā Forget about full correctness, though ā (^) Scalability to large programs essential
Conclusion
