1 / 17

Deconstruction of Dyninst : Best Practices and Lessons Learned

Deconstruction of Dyninst : Best Practices and Lessons Learned. Bill Williams. What is Componentization?. Software Project. Public Interface. Neat Idea. What is Componentization?. Software Project. Public Interface. Public Interface. Neat Idea. Component. Component. Why Components?.

briar
Télécharger la présentation

Deconstruction of Dyninst : Best Practices and Lessons Learned

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. Deconstruction of Dyninst:Best Practices and Lessons Learned Bill Williams

  2. What is Componentization? Software Project Public Interface Neat Idea Deconstruction of Dyninst

  3. What is Componentization? Software Project Public Interface Public Interface Neat Idea Component Component Deconstruction of Dyninst

  4. Why Components? • Expose existing functionality • Build new tools easily • Orthogonality • Testability • Improved code quality Deconstruction of Dyninst

  5. Dyninst and the Components = New Component = Existing Component AST = Proposed DyninstAPI Code Gen Symtab API Parse API Patch API Process Binary Binary InstructionAPI DataFlow API ProcControlAPI Stackwalker API

  6. ParseAPI: Defining the component DyninstCFG model Block Edge Cached register livenessinfo InstPoints Instrumentability Function Deconstruction of Dyninst

  7. ParseAPI: Defining the component ParseAPI CFG model Dyninstextensions Cached register livenessinfo Block Edge InstPoints Function Instrumentability Deconstruction of Dyninst

  8. PatchAPI: Refine your assumptions Deconstruction of Dyninst

  9. SymtabAPI: Creating good abstractions Great interface… …hiding messy internals XCOFF ELF PE Deconstruction of Dyninst

  10. InstructionAPI: Adding missing features Old: Control flow and not much else Deconstruction of Dyninst

  11. InstructionAPI: Adding missing features New: control flow and data flow Deconstruction of Dyninst

  12. ProcControlAPI: Build one to throw away Too many features, and I don’t need all of them! Deconstruction of Dyninst

  13. ProcControlAPI: Build one to throw away Ah, something that just does what I need! Deconstruction of Dyninst

  14. Stackwalker: When customers attack STAT requirements Dyninstrequirements Deconstruction of Dyninst

  15. DataflowAPI: Cool isn’t enough Customers: the difference between a module and a component Deconstruction of Dyninst

  16. What we’ve learned • Internal and external users driving interface design • Test new interfaces • Change codeincrementally • Keep your project’s details where they belong Deconstruction of Dyninst

  17. Componentization Tradeoffs • Stability vs. improvement • Internal requirements vs. external requirements • Development time vs. scope • Structured vs. organic • Early feedback vs. interface stability Deconstruction of Dyninst

More Related