1 / 16

Development of Symbolic Debuggers Based on Refinement Calculus

This research paper presents the development of symbolic debuggers using refinement calculus. The approach is based on generalization of translation validation and establishing refinement rules. The prototype is implemented in Prolog and can be extended for complex debuggers.

miriamreed
Télécharger la présentation

Development of Symbolic Debuggers Based on Refinement Calculus

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. Development of Symbolic Debuggers Based on Refinement Calculus RK Shyamasundar Rohit Kundaji Tata Institute of Fundamental Research Mumbai 400 005 India {shyam,rohit}@tifr.res.in

  2. Approach • Based on generalization of Translation validation (TV) • Through our proof rule: Establish Refinement • In TV one verifies each of run of the compiler rather than verify the compiler itself • We Establish Refinement Rule to arrive at semantic debuggers wherein the debuggers do not permit invalid values to be propagated corresponding to the optimizations/code generation deployed • Prototype realized in prolog; extendable for complex debuggers.

  3. Translation Validation Semantics (L) Semantic Mapping HLL L Compiler (Code Gen) Verification Semantic Mapping Semantics (A) Object A

  4. Translation Validation • The notion of refinement forms the basis of correct translation: Show the existence of a “Refinement Function” which maps each concrete state to a corresponding abstract state. • System S is defined by <V,O,Θ,Τ> where • V: Variables • O: Observable Variables • Θ: Initial Conditions • Τ: Transition Relations

  5. Proof Rule: Establish Refinement • Prove Concrete code SC implements Abstract code SA • Establish Control Abstraction Κ: CPC → 2CPA mapping each value of concrete control variable to one or more value of abstract control variable • For each node p in the source, form invariants ΦAP and ΦCP. • Establish a Data Abstraction Mapping, α which relates variables in concrete and abstract systems.

  6. Establish Refinement (Contd) • For each pair of nodes i,j with a simple path between them, prove validity • The control abstraction and data abstraction mapping represent the “Refinement Function”, while the invariants ensure that this function is consistent throughout the program.

  7. Our Approach • Automation of Translation validation. • We take the approach of using the refinement function discovered in the translation validation phase to map between the abstract and concrete states during symbolic debugging. • Implementation: Code the Refinement Function as PROLOG rules. Mapping achieved by queries. • Invariants allow consistency checks when modifying source variable values: Do not allow modifications of properties that have been the basis of optimizations in code generation

  8. Example Source: Target: L0: a=0; L1: if(a) l0: { ra := 0; L5: c = (a+b) - (a+b)/4; l1: rd := rb >> 2; } l3: add c := rb-rd; else l4: { L3: c = (b-a) - (b-a) / 4; } L4: Table 1: A Simple Example (Constant propagation, constant folding, unreachable code elimination,common subexp elimination

  9. A Simple Illustration

  10. Mapping Abstract Location to Concrete Location. • Achieved by query of type: map( [ ΠC,_,_,_, … ] ,[πA,_,_,_ , …] ). • In our example: • map( [ PI_C,_,_,_,_ ] , [0,_,_,_,_ ]). • Prolog responds with: PI_C = 0 ?; /*location l0 in concrete …*/ no /*…and no other location(unique)*/ |?-

  11. 2. Mapping Concrete Location to Abstract Location • Achieved by query of type: map( [ πC,_,_,_, … ] ,[ ΠA,_,_,_ , …] ). • In our example: • map( [1,_,_,_,_ ] , [PI_A,_,_,_,_ ]). • Prolog responds with: PI_A = 1 ?; /*location L1 in abstract…*/ no /*…and no other location (unique)*/ |?-

  12. Mapping Concrete State to Abstract State • Achieved by query of type: map([ πC,v1C,v2C,v3C,…],[ ΠA,V1A,V2A,V3A,…]). • In our example: • map( [1 , 0 , 8 , _ , _ ] , [PI_A , A , B , C]). • Prolog responds with: • A=0 • B=8 • PI_A = 1 ?; /*concrete state…*/ • no /*…and no other state(unique)*/ • |?-

  13. 4.Mapping Concrete State to Abstract State • Achieved by query of type: • map([Π C,V1C,V2C,V3C,…],[πA, v1A,v2A,v3A,…]). • In our example: • map( [ PI_C , RA , RB , RC ] , [1 , 0 , 8 , _ ]). • Prolog responds with: • RA=0 • RB=8 • PI_C = 1 ?; /*concrete state…*/ • no /*…and no other state(unique)*/ • |?-

  14. 5. Detecting Inconsistent • Changes in Abstract System • Suppose we modify value of ‘a’ to 1: • Query: • map( [ PI_C , RA , RB , RC ] , [1 , 1 , 8 , _ ]). • Prolog responds with: • no /* no possible state */ • |?-

  15. Discussion Through Translation validation, we have been able • realize specification of semantic debuggers in a declarative way • prototype implementation through Prolog • More Complex semantic debuggers can be specified and realized • Work in progress: Application of TV • For mobile code certification, debuggers for optimized code (Transparent debuggers), etc.

More Related