Faculty Summit

1
Using Phoenix for Exploring Whole Execution
Traces
Rajiv Gupta Sriraman Tallam Xiangyu Zhang The
University of Arizona
2
Execution Histories
Debugging Scenarios
3
Whole Execution Trace Representation

• Static Program Representation
• Control flow graph
• Program Dependences
• Data and control dependences
• Dynamic Profile Representation
• Designed for Analysis
• Annotates static program representation
• Related information can be easily accessed
• Comprehensive
• Control flow
• Addresses and values
• Data and control dependences
• Compact
• Design compression techniques

4
Compacted WET Sizes
5
Dynamic Slicing
6
Comparison of Dynamic Slices
How often erroneous statement is in the dynamic
slice?
Assignments
Predicates
7
Comparison of Dynamic Slices
Slice Sizes
8
Dynamic Matching Comparison Checking
Source Code

• Drawbacks
• Compiler writer must produce mappings
• Compiler modification may not be possible

9
Comparison Checking ESEC-FSE 2005
10
Profiling Using Phoenix PACT 2005

• Captured Control Flow Trace
• Parsed the CFG and inserted printf bbid
  instructions at the beginning of every basic
  block.
• lt 100 lines of programming.
• Captured Memory Dependence Trace
• At Store instructions
• Inserted a call to a DLL function storei that
  saves the address and instruction id in a hash,
  indexed by the address.
• At Load instructions
• Inserted a call to a DLL function loadi that
  looks up the hash with the memory address to
  obtain the dependence.
• Captured extended Control Flow Trace
• Additional control flow captures dependences.

11
Experience with Phoenix

• SPEC2000 benchmarks ? Native Binary.
• Native binary ? Phoenix Lowest level IR.
• Instrument IR ? inserts print bbid instructions
  and calls to loadi and storei in a DLL.
• Implement loadi and storei in the DLL
  separately.
• Write out the binary and generate the new DLL.
• Using DLLs simplified the programming.
• lt 300 lines of programming, mainly implementing
  storei and loadi in the DLL.