1. Static Program Analyses of DSP Software Systems Ramakrishnan Venkitaraman and Gopal Gupta

2. Software cost always on the rise

3. Why do we need a software standard? Lack of software reuse, because of lack of software standards. Non availability of a rich set of COTS components. Time to market new products, measured in years rather than months. Incompatibilities, make integration of software from multiple vendors impossible.

4. TI TMS320 DSP Algorithm Standard Contains 35 rules and 15 guidelines. Advantages include. Easy integration of compliant algorithms. Reduces time to market. Enables a rich set of COTS market place. Increases software reuse.

5. General Programming Rules No tool currently exists to check for compliance. SIX rules. 1) All programs should follow the runtime conventions of TI’s C programming language. 2) Algorithms must be re-entrant. 3) No hard coded data memory locations. 4) No hard coded program memory locations. 5) Algorithms must characterize their ROM-ability. 6) No peripheral device accesses.

6. The Problem and Our Approach Problem: Detection of hard coded addresses in programs. Our approach: We use “static program analysis” to detect the presence of hard coded addresses.

7. Hard Coded Addresses Generally a bad programming practice unless you are programming for device drivers. Results in non relocatable code. Results in non reusable code.

8. Static Program Analysis Static program analysis is defined as, any analysis of a program, carried out, without completely executing the program. The traditional data-flow analysis, found in compiler back-ends, is an example of static analysis. Another example of static analysis is abstract interpretation, in which, a program's data, and operations are approximated, and the program abstractly executed.

9. Why Static Analysis? In general, most interesting problems are undecidable, and so is this. We cannot just look at the code (without analysis), and say whether its hard coded. So, we need to do approximate analysis. With static analysis, we symbolically execute (abstract interpretation), the interesting parts of the code.

10. Overview of our approach Input: object code of the algorithm Output: compliant / not compliant status Activity Diagram for our Static Analyzer

11. Approach (Contd…) The basic aim of the analysis, is to find a path, from the point at which the dereferencing of a pointer occurs, to the point at which an address is assigned to the pointer, and then check, whether the source of the pointer is legitimate or not.

12. Some examples showing hardcoding void main() { int * p = 0x8800; // Some code *p = …; } Example1: Directly Hardcoded void main() { int *p = 0x80; int *q = p; //Some code *q = …; } Example2: Indirectly Hardcoded void main() { int *p, val; val = …; if(val) p = 0x900; else p = malloc(…); *p; } Example3: Conditional Hardcoding NOTE: We don’t care if a pointer is hard coded and is never dereferenced.

13. Basic Blocks and Flow Graphs A “Basic Block”, is a sequence of consecutive statements, in which flow of control enters at the beginning, and leaves at the end, without halting, or possibility of branching, except at the end. The basic blocks, form the nodes in a directed graph, called the “Control Flow- Graph”.

14. Phases in Static Analysis of the Flow Graph  Phase 1: The analyzer detects statements in the disassembled code, which correspond to the dereferencing of pointer variables, by scanning downwards in the flow graph  Phase 2: The analyzer checks whether any dereferencing detected in phase 1, is safe by scanning upwards in the flow graph

15. Phase1 - Detecting Dereferencing Start from the first node in the basic block. Keep scanning down, until the dereferencing of a register other than Stack Pointer is detected. Initialize the unsafe set with the register that was dereferenced.

16. Phase 2- Check if dereferencing is safe Made by scanning backward in the control flow-graph from the point of dereferencing. Look for statements in which, an element from the unsafe set, (in this case `Reg') is used as the destination register.

17. Building Unsafe Sets  The First element is added to the unsafe set, when phase 1 detects dereferencing.  Example: If we find “ *Reg ” in the disassembled code, the unsafe set is initialized to {Reg} int main() { int * Reg = malloc(sizeof(int)); //Some Code; *Reg = 5; }

18. Building unsafe sets (continued) Phase 2 populates the unsafe set. For example, if we find Reg = reg1 + reg2, the element “Reg” is deleted from the unsafe set, and the elements “reg1”, and “reg2”, are inserted into the unsafe set. Contents of the unsafe set will now become {reg1, reg2}.

19. Merging Information Assume that we are scanning up from block E. When at top of block D, we need to scan blocks B and C separately. Merge information when we want to scan block A after scanning B and block C. If we do not merge information, scanning will be of exponential complexity. Especially true in the case of looping constructs like “while” loops, “for” loops… Merging results in information loss. If (Cond) Then Block B Else Block C Block D Block A Block E

20. Handling Loops Complex because the number of iterations of the loop may not be known until runtime. We scan and cycle through the loop until the unsafe set reaches a “fixed point”. A fixed point is reached when. The unsafe set repeats itself at the same point in the loop during successive iterations. No new information is added to the unsafe set during successive iterations.

21. Handling Parallelism The || characters signify that an instruction is to execute in parallel with the previous instruction Instructions A, B, C are executed in parallel Example Instruction A || Instruction B || Instruction C

22. Analysis Stops when… All pointer dereferencing in the program are declared to be “safe” (not hard coded) Or At least one of the pointer dereferencing in the program is declared to be “unsafe” (hard coded)

23. Sample Code

24. Fig. Flow Graph

25. Conclusion Hardcoding is a bad programming practice and results in non relocatable/reusable code. Our work so far, can be regarded as an attempt to demonstrate, the efficacy of static analysis, to perform these checks, and aid in software reuse.

26. References Ramakrishnan Venkitaraman and Gopal Gupta, “Static Program Analysis to Detect Hard Coded Addresses and its Application to TI's DSP Processor”, CS department technical report UTD CS-23-03 For More information, Visit: http://www.utdallas.edu/~gupta/alps/ http://www.utdallas.edu/~ramakrishnan/

27. Questions…

28. Additional Slides Click to continue…

29. Handling Function Calls Similar to a branch statement Marks the beginning and end of basic blocks Recursive function calls are handled as if they were looping constructs

30. Interpretations Using Static Analysis

31. Hard Coded Pointer? The analyzer adopts a set of criteria to decide whether a dereferencing is hard coded or not. A register corresponding to a pointer is hard coded if its assigned a constant value as in the statement “Reg=0x8800". Some of the ways in which an address could be legitimate are If the address is derived from a call to memory allocation routines like “malloc" or “calloc" If the address is derived as a function of the “stack pointer" If the address is derived from another pointer that is legitimate.

32. Our Algorithm for Static Analysis 1) Get the disassembled code from the input object code. 2) From the disassembled code, get the basic blocks. 3) From the basic blocks, construct the flow-graph. 4) Analyze the flow-graph, and check for the dereferencing of pointer variables. 5) For each such dereferencing, scan back, and find out from where did this pointer get its value from (involves the formation of unsafe sets which are explained later) If the original source of this pointer is hard coded, then declare that the algorithm is not compliant (“unsafe"). If the original source from of this pointer is legitimate, then declare that dereferencing is safe. 6) The algorithm is declared to be safe, if and only if, all such pointer dereferencing are safe.

33. Merging Information (Contd) If S1 and S2 are the unsafe sets corresponding to the “then” and “else” cases, merging them will result in a new set say S3 which is {S1 union S2} S3 is a set of sets and the hard coding check is made for each set in the set of sets. By merging information, we lose some information (Cannot say which particular path the unsafe set corresponds to)

34. Related Work Compared to Dynamic Analysis, Static Analysis can give correct results, for a larger set of cases, because of the very nature of the analysis

35. Current Work Current work includes fine tuning the handling of loops and extending our system for the remaining rules. The development and testing of the tool is currently in progress.