Static Program Analysis of Embedded Software

1. Static Program Analysis of Embedded Software Ramakrishnan Venkitaraman Graduate Student, Computer Science Advisor: Dr. Gopal Gupta http://www.utdallas.edu/~gupta/alps/

2. Outline • Importance of Software Standards. • Static Analysis based tool developed by us to enforce software standard compliance. • How the marriage between industry and university research increases software reuse.

3. Why Software Standard? • Incompatibilities make integration difficult. • Complexity in software reuse. • COTS Marketplace. • Time to Market.

4. TI XDAIS Standard • Contains 35 rules and 15 guidelines. • SIX General Programming Rules. • No tool currently exists to check for compliance. • We want to build a tool to ENFORCE software compliance for these rules.

5. Problem and Solution • Problem: Detection of hard coded addresses in programs without accessing source code. • Solution: “Static Program Analysis”

6. Hard Coded Addresses • Bad Programming Practice. • Results in non relocatable code. • Results in non reusable code.

7. Static Analysis • Defined as any analysis of a program carried out without completely executing the program. • Un-decidability: Impossible to build a tool that will precisely detect hard coding.

8. Overview Of Our Approach • Input: Object Code of the Software • Output: Compliant or Not Compliant status Obtain Basic Blocks Split Into Functions Disassemble Object Code Output the Result Static Analysis Obtain Flow Graph Activity Diagram for our Static Analyzer

9. Basic Aim Of Analysis • Find a pathto trace pointer origin. • Problem: Exponential Complexity • Static Analysis approximation makes it linear

10. Phases In Analysis • Phase 1: Find the set of dereferenced pointers. • Phase 2: Check the safety of dereferenced pointers.

11. Building Unsafe Sets (Phase 1) • The first element is added to the unsafe set during pointer dereferencing. • E.g.If“*Reg” in the disassembled code, the unsafe set is initialized to {Reg}. • ‘N’ Pointers Dereferenced  ‘N’ Unsafe sets • Maintained as SOUS (Set Of Unsafe Sets)

12. Populating Unsafe Sets (Phase 2) • For e.g., if • Reg = reg1 + reg2, the element “Reg” is deleted from the unsafe set, and the elements “reg1”, “reg2”, are inserted into the unsafe set. • Contents of the unsafe set will now become {reg1, reg2}.

13. Handling Loops • Complex:# iterations of loop may not be known until runtime. • Cycle the loop until the unsafe set reaches a “fixed point”. • No new information is added to the unsafe set during successive iterations.

14. Merging Information • If no merging, then exponential complexity. • Mandatory when loops • Information loss. Block A If (Cond) Then Block B Else Block C Block D Block E

15. Extensive Compliance Checking • Handle all cases occurring in programs. • Single pointer, double pointer, triple pointer… • Global pointer variables. • Static and Dynamic arrays. • Function calls. • Pipelining and Parallelism. • …

16. Analysis Stops when… • Compliance of all the pointers are established. • Errors and warnings are reported. • Log file containing statistics of the analysis is created.

17. Analysis Results

18. Current Status and Future Work • Prototype Implementation done • But, context insensitive, intra-procedural • Extend to context sensitive, inter-procedural. • Extend compliance check for other rules.

19. So… • Hard Coding is a bad programming practice. • Non relocatable/reusable code. • A Static Analysis based technique is useful and practical.

20. Questions… Ramakrishnan Venkitaraman Graduate Student, Computer Science ramakrishnan@student.utdallas.edu