1 / 17

The DPCL Hybrid Project

The DPCL Hybrid Project. James Waskiewicz. Background: What is DPCL?. C++ API for runtime instrumentation Uses Dyninst API (variant) for instrumentation Network layer for dispatching inst requests and collecting data.

elinor
Télécharger la présentation

The DPCL Hybrid Project

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related