1. University of Maryland Paradyn as a Strict Dyninst Client James Waskiewicz

2. University of Maryland Motivation Low-level instrumentation code base has two classes of users –Paradynd –Dyninst API users This has led to… –Internal code fragmentation (ifdefs, etc) Un-necessarily complex internal code (doing reliable instrumentation is hard enough!) –Testability issues –Extra complexity in the development process A cleaner, more manageable code base ! –We’ve been talking about this for years –Its time to actually do something

3. University of Maryland Goals Dyninst does instrumentation Paradyn uses instrumentation to do performance analysis –Currently does instrumentation using the same low-level code that Dyninst API uses Need to: –Migrate paradyn-specific code from the low level code base to paradynd –“Rephrase” code in paradynd to use the publicly exported Dyninst interface –Augment DyninstAPI with functionality that is currently paradyn-specific

4. University of Maryland Basic Process: low-level -> paradynd Isolate paradyn-specific concepts –Included/excluded functions –“Resources” –traceLink – a pipe to libparadynRT Find ways to migrate these to paradynd – using existing APIs if possible (and reasonable) Add APIs to Dyninst as necessary to support paradyn’s existing needs –Added APIs should be generally useful for other DyninstAPI users

5. University of Maryland Basic Process 2: paradynd using dyninst Exhaustively track down every single reference to the low level code –This is a rather large problem –Luckily, much low-level code in paradynd has an existing analogue on the BPatch layer –Unfortunately, there are some gaping holes in DyninstAPI that need to be filled in Eg: Instrumenting threaded targets Divide and Conquer –By “subsystem” in paradynd – eg: MDL –By low level class (eg: remove all references to class “AstNode”)

6. University of Maryland Divide and Conquer: MDL MDL (Metric Definition Language) is responsible for converting high-level instrumentation requests into low-level, nuts-and-bolts instrumentation code. –Eg. “Measure the amount of time the process spends in the execution of function foo(), in module bar.c” –Typically requires navigation of source objects (modules, functions, variables, etc). –Instrumentation code represented as AstNodes MDL modified to use BPatch-layer symbols –Eg. Use BPatch_module instead of pdmodule MDL modified to use BPatch-layer code generation –Eg. Use BPatch_snippet instead of AstNode –Currently uses BPatch_snippet infrastructure, but code insertion still relies on AstNode

7. University of Maryland Divide and Conquer, con’t. Migrated concept of included/excluded functions/modules from Dyninst to paradynd –Provides a way for paradyn to restrict which functions/modules are available for performance analysis No internal representation will be created for an “excluded” function/module –A paradyn-specific concept Modified paradynd init to use –loadLibrary() to load libparadynRT –BPatch_snippets instead of instMappings

8. University of Maryland Some Added APIs When to add something? –Concept used by paradyn, but not yet exported via dyninstAPI –Must be “generally useful” to tool builders (other than paradyn) BPatch_regExpr –New type of BPatch_snippet representing the contents of a specific register –Exports AstNode::DataReg

9. University of Maryland Some Added APIs, con’t Thread Event Callbacks –registerThreadEventCallback(), allows users to provide callbacks for thread events Eg. Thread creation, thread termination, context-switch –Callbacks may be specified on either mutator- side, or in the mutatee as BPatch_functions –Prototypes: bool registerThreadEventCallback( BPatch_asyncEventType t, BPatchThreadEventCallback cb) bool registerThreadEventCallback( BPatch_asyncEventType t, BPatch_function *cb)

10. University of Maryland Some Added APIs, con’t Dynamic Call Callbacks –A dynamic call site is a call site where the called function cannot be determined statically (eg. functions called by function pointer) registerDynamicCallCallback() –allows users to provide a callback to report dynamic call events directly to the mutator bool registerDynamicCallCallback( BPatchDynamicCallSiteCallback cb) BPatch_point::monitorCalls() –Provide mutatee-side callback for dynamic call sites bool monitorCalls(BPatch_function *cb) – must be provided in a user-loaded shared library – must adhere to a prescribed prototype

11. University of Maryland More on New Event Callbacks Events are asynchronous –Mutatee is NOT stopped –Reported via socket connection with mutatee DyninstAPI is now threaded –A BPatch-layer asynchronous event handling subsystem runs on a pthread –A global mutex controls access to ALL internal Dyninst data structures Future locking refinement anticipated, depending upon performance considerations Modular Implementation: BPatch_eventLock –Locking implemented via a base class to most exported BPatch-layer classes –Does NOT require tools using dyninst to be thread safe

12. University of Maryland Event Callbacks, con’t The current plan: Three (or more) threads in Dyninst –Primary mutator thread (tool) –Synchronous process event handling thread (wait for a mutatee signal) –Asynchronous event handling thread (detect events without stopping the mutatee) Why? –Solves problem of multiple event sources –Should greatly simplify existing (synchronous) process event handling code

13. University of Maryland As We Speak… Fully migrate class “resource” from low-level code to paradyn –Used by paradyn for source navigation –Another Paradyn-specific concept Continued work on internal threading –More platforms: currently only power-AIX, x86-linux, and sparc-solaris –Current implementation “transitional” until three-thread system can be completed Stability questions will persist until then –In place, but still in progress. Full multithread support –Thanks to Matt Legendre

14. University of Maryland Coming up… More of the same –Iterative elimination of low level code from paradyn/paradynd Dovetail with MT support –Crucial to Paradyn-on-top-of-Dyninst –Active discussion under way