1. University of Maryland The DPCL Hybrid Project James Waskiewicz

2. University of Maryland Background: What is DPCL? C++ API for runtime instrumentation  Uses Dyninst API (variant) for instrumentation  Network layer for dispatching inst requests and collecting data.  Designed for instrumenting parallel programs, possibly running on multiple nodes. Some DPCL primitives include:  Process – qualified by host  Probe – inst. code (like BPatch_snippet)  Source Object – symtab abstractions (modules, functions, variables, statements…)  InstPoints – where Probes are inserted.

3. University of Maryland DPCL Overview (schematic) Client machine DPCL Tool libdpcl.so Target machine 1 Target Process 1 Target Process N Target machine N

4. University of Maryland Target machine 1 Target Process 1 dpclSD DPCL Overview (schematic) Client machine DPCL Tool libdpcl.so dpclSD Target Process N Process::connect() Contacts Super Daemon SD Performs Security Init Target machine N

5. University of Maryland Target machine 1 Target Process 1 dpclSD DPCL Overview (schematic) Client machine DPCL Tool libdpcl.so dpclSD Target Process N Process::connect() SD spawns DPCL Daemon Transfers communications DPCL daemon Dyninst API DPCL daemon Dyninst API Target machine N

6. University of Maryland Target machine 1 Target Process 1 dpclSD DPCL Overview (schematic) Client machine DPCL Tool libdpcl.so dpclSD Target Process N Process::connect() Daemon attaches to target Loads runtime library DPCL daemon Dyninst API DPCL daemon Dyninst API libdpclRT Target machine N

7. University of Maryland Target machine 1 Target Process 1 dpclSD DPCL Overview (schematic) Client machine DPCL Tool libdpcl.so dpclSD Target Process N Source Navigation: Find interesting objects InstPoints, functions, etc. DPCL daemon Dyninst API DPCL daemon Dyninst API libdpclRT Target machine N Symtab data

8. University of Maryland Target machine 1 Target Process 1 dpclSD DPCL Overview (schematic) Client machine DPCL Tool libdpcl.so dpclSD Target Process N Instrumentation: Insert Probes at InstPoints OneShot / Phase Probes DPCL daemon Dyninst API DPCL daemon Dyninst API libdpclRT Target machine N Instrument target

9. University of Maryland Target machine 1 Target Process 1 dpclSD DPCL Overview (schematic) Client machine DPCL Tool libdpcl.so dpclSD Target Process N Main Loop: Probes return instrumentation data as target application runs DPCL daemon Dyninst API DPCL daemon Dyninst API libdpclRT Target machine N Data from Probes

10. University of Maryland Motivation for the Hybrid Two Dyninsts, no longer compatible  Divergent APIs  Significant implementation differences Want DPCL on Dyninst platforms  DPCL supports Power-AIX and to a lesser extent, x86-Linux  Dyninst supports a broader range of platforms Re-introduce compatibility  Porting Dyninst is the hard part  DPCL porting made much easier – API library and communications layer.

11. University of Maryland “Phase 2” – New Priorities Practical reunification is primary goal  Minimize changes to DPCL to facilitate CVS integration  Dyninst taking the brunt of modifications Many small API modifications / additions Implement functions like addSharedLibrary(), get_demangled_name(), get_inc_points(), etc… Use std::vector<> instead of BPatch_Vector<>  Example DPCL modifications: Rewrite Probe Module code to use loadLibrary() Account for different interpretations of some symbol table information (module names, types) Lots of changes to Autoconf files  AIX: compile Dyninst with xlC, not g++ Ultra-conservative approach until hybrid work makes it into DPCL CVS tree

12. University of Maryland Simple Configuration (ease-of-use) Share-ability is critical Hybrid is integrated closely with DPCL Autoconf scripts. Configuration and build parameters are automatically substituted into the DPCL build. Headers, libraries, env. vars, etc. Configuration procedure: Set up Dyninst env. vars../configure –enable-md-dyninst (g) make. That’s it.

13. University of Maryland Testability Test suite restructured for portability As platforms are added, need to move beyond shell script configuration to keep test suite usable. Use autoconf/make instead of shell scripts Push towards completeness Some basic DPCL concepts still not represented in test suite. Eg. Phase probes, variable allocation, many types of Probe Expression.

14. University of Maryland The DPCL Command Line Interface Provides generic, minimal DPCL tool  Like Dyner – uses TCL interpreter  Provides “easy access” to DPCL Rapid prototyping (try new ideas fast) DPCL Developer debugging tool  Shooting for completeness without overhead (Expose DPCL without any new abstractions)  Scriptable Short TCL scripts can be used to test elements of DPCL Looking to use CLI to expand test suite Demo tomorrow

15. University of Maryland DPCL Command Line Interface

16. University of Maryland IA-64 DPCL Port SGI interested in DPCL for building performance tools for IA-64 Altix –Building from the hybrid work-in-progress –Not yet committed to “production code”, but… –Appears to be making rapid progress here Already seeing results –DPCL at least partially working on IA-64 Tangible benefits already emerging from the Hybrid Project

17. University of Maryland Roadmap Legal documents (still waiting… sigh) Introduction of Hybrid to DPCL CVS –Most changes under DYNINST_IBM flag –IBM code review and in-house testing Conservative approach to changing DPCL should make this a smooth process –Hybrid expected to immediately become the standard DPCL for x86-Linux CVS commit access –Will need to maintain compatibility –Less energy spent on out-of-CVS version control and synchronization –Everything becomes much easier