Presentation on theme: "Comparison of Different Techniques for Implementing Function Call and Return for CPA Checker Pashootan Vaezipoor."— Presentation transcript:
Comparison of Different Techniques for Implementing Function Call and Return for CPA Checker Pashootan Vaezipoor
Current Implementation We use a stack to store all the relevant data that we want to preserve in every function call-return Currently we store that data in a stack data structure in CompositElement class. All the elements within the same function scope have references to that stack. But whenever we have a function call, we clone the stack and put: – Caller Function Name – Current CFA Node – Current Composite Element In a CallElement and put it on top of the stack
Current Issues For this to work, we have to treat the CompositElement class differently from other element class like UninitAnalysisElement But they are all considered to be subtypes of the AbstractElement interface What would happen if we try to have a hierarchy of analysis?
What’s the next design decision? We now are trying to take out the stack from the CompositeElement class and put it in a dedicated AbstractElement class and in a dedicated domain. But still accessing the contents of the other abstract elements would be an issue
Schwartzbach’s Method In the Schwartzbach’s lecture notes, this simple method is presented: – We start by introducing a collection of shadow variables: For every function f we introduce the variable ret-f, which corresponds to its return value For every call site we introduce a variable call-i, where i is a unique index, which denotes the value computed by that function call We introduce a variable save-i- x We introduce a variable temp-i- x temporary
Schwartzbach’s Method (2) This way, every analysis is responsible for its own function call-and-return method. But it’s a very rare and primitive way of doing this task, and we still can have this result by putting the stack in each AbstractElement