The DPCL Hybrid Project

1. The DPCL Hybrid Project James Waskiewicz

2. 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. Target machine 1 Target Process 1 DPCL Overview (schematic) Client machine DPCL Tool libdpcl.so Target machine N Target Process N

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

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

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

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

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

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

10. 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. “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. 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. 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. 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. DPCL Command Line Interface

16. 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. 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