1 / 30

TDB: A Source-level Debugger for Dynamically Translated Programs

This paper presents a new execution vehicle for software security, bug isolation, simulations, and dynamic optimizations. It introduces Software Dynamic Translation (SDT) as a layer between application programs and the host machine, with the goal of debugging the application transparently to SDT. The paper outlines the challenges of debugging dynamically translated programs and proposes a debug architecture with dynamic debug mappings and techniques to generate these mappings at runtime. It also discusses the implementation, experimental results, and the extensibility of the approach.

wingler
Download Presentation

TDB: A Source-level Debugger for Dynamically Translated Programs

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. TDB: A Source-level Debugger for Dynamically Translated Programs Department of Computer Science University of Pittsburgh Pittsburgh, Pennsylvania 15260 {naveen, childers}@cs.pitt.edu Naveen Kumar, Bruce Childers Mary Lou Soffa Department of Computer Science University of Virginia Charlottesville, Virginia 22904 soffa@virginia.edu

  2. New execution vehicle • New execution vehicle for: • software security, bug isolation, simulations, dynamic optimizations…. • Software Dynamic Translation (SDT) • A layer between application program and the host machine • Intercepts and modifies instructions before they execute • Goal: Debug the Application transparent to SDT

  3. Challenges to debugging • Static debug information is inconsistent • Code is generated and modified during execution • Code duplication at run-time • Transparency of dynamic translation • Hide the SDT system • Hide the effects of dynamic translation (code modifications) on the translated code

  4. Our approach • A debug architecture for debugging dynamically translated programs • Dynamic debug mappings • Relate untranslated code with translated code • Techniques to generate these mappings at run-time for different kinds of translation operations • Extensibility: support different uses of SDT

  5. Outline • Background • Debug Architecture • Debug Mappings • Implementation • Experimental Results • Summary

  6. Background • Software Dynamic Translation (SDT) • Primary tasks • Fetch application instructions • Decode • Translate (modify/instrument) • Emit translated code into a code cache Application Binary Fetch Fetch Decode Decode Translate SDT Emit Next PC Code Cache Host CPU

  7. SDT Direct Execution & Cache Many Operation: One instruction results in more than one translated instruction Regular Operation: One instruction translates into exactly one instruction in code cache Delete Operation: Translation of an instruction results in zero instructions Trampoline Operation: Translation of a branch results in a set of instructions to invoke translator Program Code Code Cache Translator ld [ %o1 ], %o0 ld [ %o1 ], %o0 call 0x26a70c sethi hi(0x50400),%o7 or %o7, 0x288, %o7 nop nop ld [ %o1 ], %o0 call 0x26a70c branch re-enter fetch fragment … execute fragment … … branch trampoline be 0x26a77c mov %g0, %o0 mov %g0, %o0 Fetch code fragment until end of fragment condition Execute code fragment until branch trampoline

  8. Outline • Background • Debug Architecture • Debug Mappings • Implementation • Experimental Results • Summary

  9. Debug Architecture Native Debugger Mapping Repository Mapper Breakpoint Manager Breakpoint Repository Mapping Generator Debug Engine Application SDT System Code Cache

  10. Debug Engine Mapping Repository Mapper Breakpoint Manager Breakpoint Repository Mapping Generator Debug Engine Translation information from SDT system

  11. Debug Engine mapAddress or writeValue from Native Debugger Mapping Repository Mapper Breakpoint Manager Breakpoint Repository Mapping Generator Debug Engine Read/Write into Code Cache Translation information from SDT system

  12. Debug Engine mapAddress or writeValue from Native Debugger insert or delete breakpoints Mapping Repository Mapper Breakpoint Manager Breakpoint Repository Mapping Generator Debug Engine Read/Write into Code Cache Translation information from SDT system

  13. Debug Engine Notify native debugger mapAddress or writeValue from Native Debugger insert or delete breakpoints Mapping Repository Mapper Breakpoint Manager Breakpoint Repository Mapping Generator Debug Engine Read/Write into Code Cache Translation information from SDT system Breakpoint Exception

  14. Outline • Background • Debug Architecture • Debug Mappings • Implementation • Experimental Results • Summary

  15. Dynamic Debug Mappings • Debug engine generates and uses debug information in terms of mappings • Mappings used to implement debug commands • Mapping types • U-T: untranslated code with translated code • T-T: translated code with translated code • T-U: translated code with untranslated code • The mappings are generated based upon the kind of translation operation (regular, many etc.)

  16. u t U-T Regular Operation(copy an instruction to code cache) 50684: ld [ %o1 ], %o0 50688: call 0x26a70c 5068c: nop … … 26a70c: mov %o0, %o1 26a710: andcc %o1,3,%o3 26a714: be 0x26a77c 26a718: mov %g0, %o0 ... ... f1800c8: ld [ %o1 ], %o0 U-T Mappings 1. 50684  {f1800c8} Program locations Translated locations Uses: Determine code cache location for inserting a breakpoint Determine untranslated location for PC, when a breakpoint is hit

  17. Many Operation(translate an instruction into multiple instructions) 50684: ld [ %o1 ], %o0 50688: call 0x26a70c 5068c: nop … … 26a70c: mov %o0, %o1 26a710: andcc %o1,3,%o3 26a714: be 0x26a77c 26a718: mov %g0, %o0 ... ... f1800c8: ld [ %o1 ], %o0 U-T Mappings 1. 50684  {f1800c8} Program locations Translated locations

  18. Many Operation 50684: ld [ %o1 ], %o0 50688: call 0x26a70c 5068c: nop … … 26a70c: mov %o0, %o1 26a710: andcc %o1,3,%o3 26a714: be 0x26a77c 26a718: mov %g0, %o0 ... ... f1800c8: ld [ %o1 ], %o0 f1800cc: sethi hi(0x50400),%o7 f1800d0: or %o7, 0x288, %o7 U-T Mappings 1. 50684  {f1800c8} Program locations Translated locations

  19. U-T t1t2t3t4 u u+1 T-T U-T Many Operation 50684: ld [ %o1 ], %o0 50688: call 0x26a70c 5068c: nop … … 26a70c: mov %o0, %o1 26a710: andcc %o1,3,%o3 26a714: be 0x26a77c 26a718: mov %g0, %o0 ... ... f1800c8: ld [ %o1 ], %o0 f1800cc: sethi hi(0x50400),%o7 f1800d0: or %o7, 0x288, %o7 U-T Mappings 1. 50684  {f1800c8} 2. 50688  {f1800cc} T-T Mappings 3. f1800d0  {f1800d4} Program locations Translated locations Uses: “Skip past” the execution of each additional instruction (e.g. t2 & t3 in the adjoining figure are never visible to the native debugger)

  20. Other Operations 50684: ld [ %o1 ], %o0 50688: call 0x26a70c 5068c: nop … … 26a70c: mov %o0, %o1 26a710: andcc %o1,3,%o3 26a714: be 0x26a77c 26a718: mov %g0, %o0 ... ... f1800c8: ld [ %o1 ], %o0 f1800cc: sethi hi(0x50400),%o7 f1800d0: or %o7, 0x288, %o7 f1800d4: mov %o0, %o1 f1800d8: andcc %o1, 3, %o3 f1800dc: be 0xff180104 f1800e0: mov %g0, %o0 f1800e4: save %sp, -96, %sp ... ... U-T Mappings 1. 50684  {f1800c8} 2. 50688  {f1800cc} 4. 5068c  {f1800d4} 5. 26a70c  {f1800d4} 6. 26a710  {f1800d8} 7. 26a714  {f1800dc} 8. 26a718  {f1800e0} T-T Mappings 3. f1800d0  {f1800d4} T-P Mappings 9. f1800e4  {26a77c} Program locations Translated locations Other operations include: Delete, Trampoline Overhead reduction operations Dynamic instrumentation

  21. Outline • Background • Debug Architecture • Debug Mappings • Implementation • Experimental Results • Summary

  22. TDB • Reference implementation of Debug Architecture • GDB as the Native Debugger • Supports all source-level commands in GDB • SDT system Strata • Basic translation operations (regular,many,delete,tramp) • Overhead reduction techniques • Dynamic instrumentation • Also used by Intel for their Pin SDT system

  23. Layout of the Debug Engine Native Debugger GDB process space Mapper Breakpoint Manager Debug Engine Mapping & Breakpoint Repositories Shared memory Mapping generator Strata process space Application + SDT System

  24. Outline • Background • Debug Architecture • Debug Mappings • Implementation • Experimental Results • Summary

  25. Experiments • Experiments • Measured time to execute one breakpoint • Measured memory overhead • Experimental setup • Strata-SPARC, GDB 5.3 • security policy on invocation of syscalls • SUN Blade 100, SPECint2000 benchmarks • Breakpoints set in "hot" functions • Programs run until 10,000 breakpoints hit

  26. Breakpoint Overhead Cost per breakpoint in GDB = 1 Average cost of breakpoint in Tdb = 1.63

  27. Memory Requirements • Memory requirement ranges from 56KB to 1.3 MB • Average of 501KB

  28. Outline • Background • Debug Architecture • Debug Mappings • Implementation • Experimental Results • Summary

  29. Summary • Proposed a debug architecture • Debug mappings • Generation and use of mappings • Available for Strata/GDB and Pin/GDB • Supports all source-level commands and queries • Has minimal performance and memory overheads

  30. For More Information Please visit http://www.cs.pitt.edu/coco/tdb University of Pittsburgh University of Virginia

More Related