Memory Access Instrumentation with Dyninst

1
Memory Access Instrumentationwith Dyninst

• Vasile Gaburiciltgaburici_at_cs.umd.edugt

2
Motivation

• Dynamic memory access instrumentation
• collect low level memory accesses
• with the flexibility of dynamic instrumentation
• Possible applications
• offline performance analysis (Sigma etc.)
• online optimization
• tools to catch memory errors

3
Features

• Finding memory access instructions
• loads, stores, prefetches
• Decoded instruction information
• type of instruction
• constants and registers involved in computing
• the effective address
• the number of bytes moved
• available in the mutator before execution
• Memory access snippets
• effective address in process space
• byte count
• available in mutatee at execution time

4
Searching for memory access instructions

• A two step process
• build a set of instruction opcodes to search for
• perform the search
• Generic opcode set specification
• encapsulated in BPatch_SetltBPatch_opCodegt
• BPatch_opCode (an enumeration) supports
• BPatch_opLoad
• BPatch_opStore
• BPatch_opPrefetch

5
Searching for memory access instructions contd

• Performing the search
• input is an instruction opcode set
• output is a vector of memory instrumentation
  points
• search is performed at function
  levelBPatch_VectorltBPatch_point gt
  Bpatch_functionfindPoint( const
  BPatch_SetltBPatch_opCodegt ops)
• there is a wrapper for this at image level
  Bpatch_ImagefindProcedurePoint()

6
Gathering data about accesses

• class BPatch_effectiveAddressExpr
• defines an expression that returns the base
  address of the memory access
• class BPatch_bytesAccessedExpr
• defines an expression that returns the base
  address of the memory access
• Both classes have nullary constructors
• these new snippets are point aware
• memory access information is extracted from the
  underlying memory instrumentation point
• this simplifies usage no need for the user
  tokeep track and pass the correct
  informationwhen the snippets are built

7
Example

• Instrument all loads and stores in function foo
  with a snippet that prints out the effective
  address
• BPatch_SetltBPatch_opCodegt axs
• axs.insert(BPatch_opLoad)
• axs.insert(BPatch_opStore)
• BPatch_VectorltBPatch_pointgtr
  img-gtfindProcedurePoint("foo", axs)
• BPatch_VectorltBPatch_snippetgt printfArgs
• BPatch_constExpr fmt("Access at d.\n")
• printfArgs.push_back(fmt)
• BPatch_effectiveAddressExpr eae
• printfArgs.push_back(eae)
• BPatch_function printfFunc img-gtfindFunction("
  printf")
• BPatch_funcCallExpr printfCall(printfFunc,
  printfArgs)
• thr-gtinsertSnippet(printfCall, r)

8
Memory instrumentation points

• are created only by memory access search
  functions
• are arbitrary instrumentation points
• May be instrumented like any other arbitrary
  points
• are the only instrumentation points that may be
  instrumented with memory access snippets
• provide the memory access information to the
  user
• Bpatch_pointgetMemoryAccess()

9
Memory accessinformation classes

• Class BPatch_memoryAccess contains
• instruction type load, store, prefetch
• combinations are possible (e.g. swap)
• prefetch additional information
• descriptor for effective address
• descriptor for number of bytes moved
• Effective address descriptor
• class BPatch_addrSpec_NP
• note non-portable and subject to change
• a sum of registers plus a constant

10
Effective address calculation

• The memory access information is used to generate
  the code that computes the effective address

AddressDescriptor
Instrumentation
load S, C

• Original valueobtained from
• live register
• stack frame
• register wheel

_restore T,R1
R2 R1 C
add S,S,T
_restore T,R2
add S,S,T
11
Memory accessinformation classes contd

• Byte count descriptor
• class BPatch_countSpec_NP
• an alias for address descriptor right now
• this may not hold in the future usually the byte
  count has a simpler form so we may implement it
  differently for optimization purposes
• Other issues
• register numbers are obvious for RISC CPUs
• pseudo registers are used to avoid complicating
  the formula with bit masks used by some CPUs
• the only one now is for PowerPC - XER 2531

12
Current Status (Dyninst 3.0)

• AIX/Power3 implementation
• no known limitations/problems
• Solaris/SPARCv9 implementation
• no VIS, VIS2 yet SPARCv9a,b
• limited support for alternate address spaces
• not all memory inst. points are instrumentable
• New test program test6
• Both implementations are 64-bit ready
• Dyninst 3.0 cannot load 64-bit images on Solaris
  or AIX
• test suite uses assembler written 32-bit
  processthat does test 64-bit instructions

13
Current/Future Work

• Intel IA-32 implementation is underway
• will support opcodes up to Pentium 4(current
  Dyninst decoder only knows Pentium)
• will require some API additions/changes
• memory to memory operations producemultiple
  targets per instruction
• conditional moves introduce conditional(predicate
  d) snippets
• introduce some abstraction for prefetches,
  currently SPARC-centric
• Building higher level libraries/tools
• Sigma project integration

14
Demo

• A simple memory profiler
• Sort functions in a program based on thevolume
  of memory traffic generated by data accesses
• Tomorrow in CS building rm. 6372