1 / 40

CIL: Intermediate Language and Tools for Analysis and Transformation of C programs

CIL: Intermediate Language and Tools for Analysis and Transformation of C programs. George C.Necula Scott McPeak S.P.Rahul Westley Weimer. University of California, Berkeley Proc. of Conference on Compiler Construction, 2002. INDEX. Author Questions Overview Introduction Evaluation.

kele
Download Presentation

CIL: Intermediate Language and Tools for Analysis and Transformation of C programs

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CIL:Intermediate Language and Tools for Analysis and Transformation of C programs George C.NeculaScott McPeakS.P.RahulWestley Weimer University of California, BerkeleyProc. of Conference on Compiler Construction, 2002

  2. INDEX • Author • Questions • Overview • Introduction • Evaluation

  3. 1st AUTHOR • George C.Necula • Scott McPeak • S.P.Rahul • Westley Weimer

  4. George C.Necula • George C. Necula, Philip Wadler: Proceedings of the 35th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, POPL 2008, San Francisco, California, USA, January 7-12, 2008 ACM 2008 • Westley Weimer, George C. Necula: Exceptional situations and program reliability. ACM Trans. Program. Lang. Syst. 30(2): (2008) • François Pottier, George C. Necula: Proceedings of TLDI'07: 2007 ACM SIGPLAN International Workshop on Types in Languages Design and Implementation, Nice, France, January 16, 2007 ACM 2007 • Jeremy Condit, Matthew Harren, Zachary R. Anderson, David Gay, George C. Necula: Dependent Types for Low-Level Programming. ESOP 2007: 520-535 • Bor-Yuh Evan Chang, Xavier Rival, George C. Necula: Shape Analysis with Structural Invariant Checkers. SAS 2007: 384-401 • Ajay Chander, David Espinosa, Nayeem Islam, Peter Lee, George C. Necula: Enforcing resource bounds via static verification of dynamic checks. ACM Trans. Program. Lang. Syst. 29(5): (2007)

  5. CONTINUED • Jens Knoop, George C. Necula, Wolf Zimmermann: Preface. Electr. Notes Theor. Comput. Sci. 176(3): 1-2 (2007) • Sumit Gulwani, George C. Necula: A polynomial-time algorithm for global value numbering. Sci. Comput. Program. 64(1): 97-114 (2007) • George C. Necula: Using Dependent Types to Port Type Systems to Low-Level Languages. CC 2006: 1 • Feng Zhou, Jeremy Condit, Zachary R. Anderson, Ilya Bagrak, Robert Ennals, Matthew Harren, George C. Necula, Eric A. Brewer: SafeDrive: Safe and Recoverable Extensions Using Language-Based Techniques. OSDI 2006: 45-60 • Úlfar Erlingsson, Martín Abadi, Michael Vrable, Mihai Budiu, George C. Necula: XFI: Software Guards for System Address Spaces. OSDI 2006: 75-88 • Bor-Yuh Evan Chang, Matthew Harren, George C. Necula: Analysis of Low-Level Code Using Cooperating Decompilers. SAS 2006: 318-335 • Bor-Yuh Evan Chang, Adam J. Chlipala, George C. Necula: A Framework for Certified Program Analysis and Its Applications to Mobile-Code Safety. VMCAI 2006: 174-189

  6. Scott McPeak • Scott McPeak, George C. Necula: Data Structure Specifications via Local Equality Axioms. CAV 2005: 476-490 • George C. Necula, Jeremy Condit, Matthew Harren, Scott McPeak, Westley Weimer: CCured: type-safe retrofitting of legacy software. ACM Trans. Program. Lang. Syst. 27(3): 477-526 (2005) • Scott McPeak, George C. Necula: Elkhound: A Fast, Practical GLR Parser Generator. CC 2004: 73-88 • Jeremy Condit, Matthew Harren, Scott McPeak, George C. Necula, Westley Weimer: CCured in the real world. PLDI 2003: 232-244 • George C. Necula, Scott McPeak, Shree Prakash Rahul, Westley Weimer: CIL: Intermediate Language and Tools for Analysis and Transformation of C Programs. CC 2002: 213-228 • George C. Necula, Scott McPeak, Westley Weimer: CCured: type-safe retrofitting of legacy code. POPL 2002: 128-139 • Dan Bonachea, Eugene Ingerman, Joshua Levy, Scott McPeak: An Improved Adaptive Multi-Start Approach to Finding Near-Optimal Solutions to the Euclidean TSP. GECCO 2000: 143-150

  7. S.P.Rahul • George C. Necula, Scott McPeak, Shree Prakash Rahul, Westley Weimer: CIL: Intermediate Language and Tools for Analysis and Transformation of C Programs. CC 2002: 213-228 • George C. Necula, Shree Prakash Rahul: Oracle-based checking of untrusted software. POPL 2001: 142-154

  8. Westley Weimer • Stephanie Forrest, ThanhVu Nguyen, Westley Weimer, Claire Le Goues: A genetic programming approach to automated software repair. GECCO 2009: 947-954 • Raymond P. L. Buse, Westley Weimer: The road not taken: Estimating path execution frequency statically. ICSE 2009: 144-154 • Westley Weimer, ThanhVu Nguyen, Claire Le Goues, Stephanie Forrest: Automatically finding patches using genetic programming. ICSE 2009: 364-374 • Pieter Hooimeijer, Westley Weimer: A decision procedure for subset constraints over regular languages. PLDI 2009: 188-198 • Tamim I. Sookoor, Timothy W. Hnat, Pieter Hooimeijer, Westley Weimer, Kamin Whitehouse: Macrodebugging: global views of distributed program execution. SenSys 2009: 141-154 • Claire Le Goues, Westley Weimer: Specification Mining with Few False Positives. TACAS 2009: 292-306

  9. CONTINUED • Nicholas Jalbert, Westley Weimer: Automated duplicate detection for bug tracking systems. DSN 2008: 52-61 • bibliographical record in XML Kinga Dobolyi, Westley Weimer: Changing Java's Semantics for Handling Null Pointer Exceptions. ISSRE 2008: 47-56 • Raymond P. L. Buse, Westley Weimer: A metric for software readability. ISSTA 2008: 121-130 • Raymond P. L. Buse, Westley Weimer: Automatic documentation inference for exceptions. ISSTA 2008: 273-282 • Xiang Yin, John C. Knight, Elisabeth A. Nguyen, Westley Weimer: Formal Verification by Reverse Synthesis. SAFECOMP 2008: 305-319 • Timothy W. Hnat, Tamim I. Sookoor, Pieter Hooimeijer, Westley Weimer, Kamin Whitehouse: MacroLab: a vector-based macroprogramming framework for cyber-physical systems. SenSys 2008: 225-238 • Westley Weimer, George C. Necula: Exceptional situations and program reliability. ACM Trans. Program. Lang. Syst. 30(2): (2008)

  10. 2nd Questions • Q1: What does the recursive structure transformation look like in CIL? • Q2: What's the implementation of Integrating a CFG into the Intermediate Language? • Q3: How do they achieve the goal of making code immune to stack-smashing attack? • Q4: What are the difficulties in designing the whole-program merger and what about implementation? • Q5: How does the merger deal with .lib and .dll?

  11. BackDraws in C Phenomenon: the same syntax but different meanings. • What if low-level representation? No ambiguities for loss of structural information about types, loops, and other high-level constructs.

  12. 3rd OVERVIEW CIL CIL is both lower-level than abstract-syntax trees, by clarifying ambiguous constructs and removing redundant ones, and also higher-level than typical intermediate languages designed for compilation, by maintaining types and a close relationship with the source program. • Feature The main advantage of CIL is that it compiles all valid C programs into a few core constructs with a very clean semantics. Translating from CIL to C is fairly easy.

  13. Q1: What does the recursive structure transformation look like in CIL?Q2: What's the implementation of Integrating a CFG into the Intermediate Language? (After transformation, call Cil.computeCFGInfo<Compute all statements and find the successor and predecessor of each statement;Return a list of statements>)

  14. 4th INTRODUCTION • Basic components • Compilation( C ---> CIL) • A whole-program merger • Representative application

  15. BASIC COMPONENTS • Lvalue An lvalue is expressed as a pair of a base plus an offset. The base address can be either the starting address for the storage for a variable (local or global) or any pointer expression.

  16. BASIC COMPONENTS • Expression & Instruction Note: Casts are inserted explicitly to make the program conform to our type system.

  17. BASIC COMPONENTS • Statement

  18. BASIC COMPONENTS • Types CIL moves all type declarations to the beginning of the program and gives them global scope.

  19. All anonymous composite types are given unique names in CIL and every composite types has its own declaration at the top-level.

  20. BASIC COMPONENTS • Attributes It is often useful to have a mechanism for the programmer to communicate additional information to the program analysis.

  21. The type attributes for a base type must be specified immediately following the type.

  22. The type attributes for a pointer type must be specified immediately after the * symbol.

  23. The attributes for a function type or for an array type can be specified using parenthesized declarators.

  24. COMPILATION • One of the most significant transformations is that expressions that contain side-effects are separated into statements.

  25. Type specifiers are interpreted and normalized.

  26. Nested structure tag definitions are pulled apart. This means that all structure tag definitions can be found by a simple scan of the globals.

  27. Prototypes are added for those functions that are called before being defined. Furthermore, if a prototype exists but does not specify the type of parameters that is fixed.

  28. Initializers are normalized to include specific initialization for the missing elements.

  29. CIL will remove from the source file those type declarations, local variables and inline functions that are not used in the file. This means that your analysis does not have to see all the ugly stuff that comes from the header files.

  30. Local variables in inner scopes are pulled to function scope (with appropriate renaming). Local scopes thus disappear. This makes it easy to find and operate on all local variables in a function.

  31. A WHOLE-PROGRAM MERGER • A tool that merges all of a program’s compilation units into a single compilation unit, with proper renaming to preserve semantics considering many analyses are most effective when applied to the whole program.

  32. Q4: What's the difficulties in designing the whole-program merger and what about implementation?

  33. File-scope identifiers must be renamed properly to avoid clashes with globals and with similar identifiers in different files.

  34. Solution: • Structural Equivalence VS Name Equivalence • For each file there are two merging phases. In the first phase we merge the types and tags.Then in the second stage we rewrite the variable declarations and function bodies.

  35. REPRESENTATIVE APP Q3: How do they achieve the goal of making code immune to stack-smashing attack? CIL modifies the program to maintain a separate stack for return addresses. Even if a buffer overrun attack occurs the actual correct return address will be taken from the special stack.

  36. 5th EVALUATION • CIL has been tested very extensively. It is able to process the SPECINT95 benchmarks, the Linux kernel, GIMP and other open-source projects. • CIL was tested against GCC’s c-torture testsuite and (except for the tests involving complex numbers and inner functions, which CIL does not currently implement) CIL passes most of the tests. Specifically CIL fails 23 tests out of the 904 c-torture tests that it should pass. GCC itself fails 19 tests.

  37. Thank you! More information athttp://hal.cs.berkeley.edu/cil/

More Related