Download CMSC 631: Program Analysis and Understanding - Fall 2004 and more Study notes Computer Science in PDF only on Docsity!
CMSC 631 ā Program Analysis and Understanding Fall 2004
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: Tuesday, Friday 11am-12pm
ā¢ Morgan Kleene
ā E-mail: kleene at cs.umd.edu
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
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
ā¢ Will read 1-3 papers per week
ā (^) Typically, papers available on the web
- Otherwise will hand out photocopies in class
ā¢ Must participate in brief discussion on class wiki
ā (^) http://corundum.cs.umd.edu:8000/CMSC ā (^) Post a few sentences to a paragraph or two on
- Main contributions/ideas in paper
- Ideas that were unclear ā what do I need to cover in class?
- Relationship to other papers weāve read
- etc...
Expectations: Readings
CMSC 631, Fall 2004 7
ā¢ Must post comments by noon on day of class
ā First post! can just put up a summary ā (^) Later posts need to take earlier posts into account ā (^) Posting earlier is less work
ā¢ 10% of grade will be on class participation,
including comments on wiki
ā (^) Includes talk on selected paper in 2nd half of course
Expectations: Readings (contād)
CMSC 631, Fall 2004 8
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 9
ā¢ 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
CMSC 631, Fall 2004 10
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
ā¢ Last year, 2 projects turned into publications
ā (^) And a couple more could have been
ā¢ 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
ā¢ Donāt do it
Academic Dishonesty
CMSC 631, Fall 2004 19
ā¢ 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 20
ā¢ 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 21
ā¢ Three syntactic forms
variable function function application
ā¢ One reduction rule
ā (replace by in )
ā¢ Can represent any computable function!
Lambda Calculus
CMSC 631, Fall 2004 22
ā¢ 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 OāCaml for programming assignments
ā¢ 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 25
in type environment , expression has type
Simply-typed Ī»-calculus
dom(A) !
!
!
!
!! !
!
CMSC 631, Fall 2004 26
ā¢ 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 27
ā¢ 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
CMSC 631, Fall 2004 28
ā 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)
||
ā¢ Program defines a state graph
ā (^) State = (pc1, pc2, x1, x2, last) ā (^) Is any bad state (iiXXX) reachable from the start state?
Transition Graph
oo 001
ro 101 or 012
io 101 rr 112
ir 112
CMSC 631, Fall 2004 37
ā¢ 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
CMSC 631, Fall 2004 38
ā¢ 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
CMSC 631, Fall 2004 39
ā¢ 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
