Proc Control API and Stackwalker API Integration into

  • Slides: 22
Download presentation
Proc. Control. API and Stackwalker. API Integration into Dyninst Todd Frederick and Dan Mc.

Proc. Control. API and Stackwalker. API Integration into Dyninst Todd Frederick and Dan Mc. Nulty Paradyn Project Paradyn / Dyninst Week Madison, Wisconsin May 2 -4, 2011

Dyninst and the Components = Existing Component = New Component = Proposed AST Code

Dyninst and the Components = Existing Component = New Component = Proposed AST Code Gen Symtab API Parse API Binary Instruction API Process Patch API Data. Flow API Stackwalker API Proc. Control API Binary

Process Control and Stackwalking in Dyninst o Process control: o Modify processes’ memory during

Process Control and Stackwalking in Dyninst o Process control: o Modify processes’ memory during instrumentation o Capture events such as exit, fork, library load o Start and stop processes and threads o Stackwalking: o Analysis during instrumentation o Provide stackwalks to users Stackwalking needs process control to access memory and registers Proc. Control. API and Stackwalker. API Integration 3

Proc. Control. API and Stackwalker. API o Already released o Who is using these

Proc. Control. API and Stackwalker. API o Already released o Who is using these components now? Proc. Control. API Stackwalker. API o proc++ Filesystem o Stackwalker. API o Dyninst o o o STAT Libra Pn. MPI ATP …and more Dyninst o Who is not using these components now? o Dyninst gains new features and stability when integrated with these components Proc. Control. API and Stackwalker. API Integration 4

Ideal Componentization Process o New components should separate existing functionality out of Dyninst o

Ideal Componentization Process o New components should separate existing functionality out of Dyninst o Keeping Dyninst in mind ensures the components work together correctly Dyninst Process Control Component Process Control Functionality Component Proc. Control. API and Stackwalker. API Integration 5

Actual Componentization Process o We developed Proc. Control. API and Stackwalker. API separately from

Actual Componentization Process o We developed Proc. Control. API and Stackwalker. API separately from Dyninst o Interfaces to these components do not exactly match Dyninst’s requirements Dyninst Process Control Component Process Control Functionality Proc. Control. API and Stackwalker. API Integration 6

Why Separate Proc. Control. API? o Clean interface to complex, notoriously buggy, OS-dependent debugger

Why Separate Proc. Control. API? o Clean interface to complex, notoriously buggy, OS-dependent debugger interfaces System Interface Linux Debugger Interface Low Level Commands Read memory Stop process Your Code/ Stackwalke r/Dyninst Windows Debugger Interface Proc. Control. API Thread events Breakpoint s Free. BSD Debugger Interface Low Level Events Proc. Control. API and Stackwalker. API Integration Blue. Gene Debugger Interface Vx. Works Debugger Interface 7

Threading inside Dyninst/Proc. Control. API o Integrating Proc. Control. API into Dyninst introduces a

Threading inside Dyninst/Proc. Control. API o Integrating Proc. Control. API into Dyninst introduces a new threading model o Leverage threads to handle multiple inputs o User API calls o System debug interface o Internal event handling o Types of threads o Event decoders o Event handlers Proc. Control. API and Stackwalker. API Integration 8

Dyninst 7. 0 Threading Model o 2 threads per mutatee process Mutator Execute callbacks

Dyninst 7. 0 Threading Model o 2 threads per mutatee process Mutator Execute callbacks Dyninst. AP Dyninst+Proc. Control. API Runtime I Update Library Event Proces data Handler s Model structures Event notifications Update Event data notifications structures User Thread Event Handlers Asynchronous events Event Decoders OS events RT RT Lib Runtime Library Target Process Mutatee Process Abstract events Proc. Control. API and Stackwalker. API Integration 9

Dyninst+Proc. Control. API Threading Model o 1 event decoder, 2 event handlers Mutator Execute

Dyninst+Proc. Control. API Threading Model o 1 event decoder, 2 event handlers Mutator Execute callbacks Dyninst. AP I Proc. Control. API Event Decoder Process Model No longer update data structures Event notification s s User Event Thread Handler Abstract events Event Handler Update data structures OS event s RT RT Lib Runtime Library Target Process Mutatee Process Model Proc. Control. API and Stackwalker. API Integration 10

New functionality with Proc. Control. API o Synchronous events for mutatee thread creation and

New functionality with Proc. Control. API o Synchronous events for mutatee thread creation and destruction o No more “Dead On Arrival” threads o Possible new Dyninst. API features o Separate kernel-level and user-level thread events o Real breakpoints and single-stepping Proc. Control. API and Stackwalker. API Integration 11

New Feature – Detach-on-the-fly Old o Useful when multiple target processes generate many events

New Feature – Detach-on-the-fly Old o Useful when multiple target processes generate many events that require no Dyninst action o e. g. , profiling timers generating signals o Temporarily detach from mutatee process Mutator Process Temporary Re-attach Forward Events Detach Events Dyninst. API Library Target Mutatee Process Events Proc. Control. API and Stackwalker. API Integration 12

Stackwalker. API and Dyninst o Many tools already use Stackwalker. API o Dyninst still

Stackwalker. API and Dyninst o Many tools already use Stackwalker. API o Dyninst still uses separate, older code for walking stacks STAT Libra Dyninst ATP Pn. MPI Stackwalker. API Old Stackwalking Functionality Proc. Control. API and Stackwalker. API Integration 13

Why Separate Stackwalker. API? o Dyninst currently has separate stackwalking functionality for each platform

Why Separate Stackwalker. API? o Dyninst currently has separate stackwalking functionality for each platform o Stackwalker. API abstracts common stackwalking patterns across platforms Stackwalking Interface Platform-Specific Stackwalking Frame Fr Debug ame Functions Informations stics Heuri Signal Instrumentatio dlners Handlers n a H l Signa Debug Informatio Platform-Specific n Support Heuristics tation Instrumen Proc. Control. API and Stackwalker. API Integration 14

Why Separate Stackwalker. API? o Stack frames on different architectures have different binary layouts

Why Separate Stackwalker. API? o Stack frames on different architectures have different binary layouts o Stackwalker. API Frame objects are a crossarchitecture representation Previous Stack Pointer Frame Pointer Stack Pointer x 86 Stack Frame POWER Stack Frame Previous Return Address Previous Frame Address . . . Pointer . . . Frame Pointer Return Address Previous Stack Pointer Return Address Previous Frame Pointer Stackwalker. API Frame • Return Address • Frame Pointer • Stack Pointer Proc. Control. API and Stackwalker. API Integration 15

New Functionality with Stackwalker. API o Extensible with frame steppers o Users can tell

New Functionality with Stackwalker. API o Extensible with frame steppers o Users can tell Dyninst how to walk through nonstandard frames o Dyninst uses this feature to handle its own instrumentation o Binary analysis-based frame stepper o Determines how binary code creates stack frames o More robust than existing heuristics o Uses Proc. Control. API for third-party walks o Improved stability by sharing Dyninst’s view of a process Proc. Control. API and Stackwalker. API Integration 16

Extending Stackwalker. API with Steppers o Frame stepper objects encapsulate the logic to walk

Extending Stackwalker. API with Steppers o Frame stepper objects encapsulate the logic to walk different kinds of stack frames o Users can add new Frame teppers, as Dyninst does to walk through instrumentation main() { signal(SIGALRM, signal_handler); alarm(1); } signal_handler() { // Instrument // with foo } Stack Frame Instrumentation Stepper foo [Dyninst Tramp] signal_handler Signal Handler Stepper Debug Information Stepper __restore_rt main __libc_start_main foo() { walk. Stack(); } _start Proc. Control. API and Stackwalker. API Integration 17

Analysis-Based Stackwalking o Our analysis tracks how each instruction changes the height of the

Analysis-Based Stackwalking o Our analysis tracks how each instruction changes the height of the stack 0 x 0: 0 x 1: 0 x 4: 0 x 8: PUSH MOV SUB. . . RBP RSP, RBP 40, RBP Stack Frame 0 x 1: -16 0 x 8: -56 Stack Pointer Analysis: Stack Heights 0 x 0: -8 0 x 4: -16 Stack Pointer Proc. Control. API and Stackwalker. API Integration 18

Analysis-Based Stackwalking o Using the stack height at an instruction, we determine how to

Analysis-Based Stackwalking o Using the stack height at an instruction, we determine how to find the next stack frame 0 x 0: 0 x 1: 0 x 4: 0 x 8: PUSH MOV SUB. . . RBP RSP, RBP 40, RBP Stack Frame Object Stack Pointer Analysis: Stack Heights 0 x 0: -8 0 x 1: -16 0 x 4: -16 0 x 8: -56 Proc. Control. API and Stackwalker. API Integration Frame Object Stack Pointer 19

Where we are o In-development version of Dyninst fully integrated with Proc. Control. API

Where we are o In-development version of Dyninst fully integrated with Proc. Control. API and Stackwalker. API o Stable on Linux o Incomplete platform support for Proc. Control. API and Stackwalker. API Linux Windows Free. BSD Vx. Works BG/P Proc. Control. API Stackwalker. API Proc. Control. API and Stackwalker. API Integration 20

Dyninst 8. 0 o Complete support of Proc. Control. API and Stackwalker. API on

Dyninst 8. 0 o Complete support of Proc. Control. API and Stackwalker. API on all missing platforms o Dynamic instrumentation on new platforms o Blue. Gene/P, Free. BSD o New features from integration effort o Detach-on-the-fly o Binary analysis-based frame stepper Proc. Control. API and Stackwalker. API Integration 21

Questions Proc. Control. API and Stackwalker. API Integration 22

Questions Proc. Control. API and Stackwalker. API Integration 22