1 / 23

Source Level Debugging in Allegro CL

Source Level Debugging in Allegro CL. By Duane Rettig with Willem Broekema. March, 2009. Outline. Introduction Requirements and History Demos (both Lisp and Python) ‏ Design Issues and Future Work. Why has it taken so long?. Lisp is symbolic Lisp is dynamic Lisp has hooks

tansy
Download Presentation

Source Level Debugging in Allegro CL

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. Source Level Debugging in Allegro CL By Duane Rettig with Willem Broekema March, 2009

  2. Outline • Introduction • Requirements and History • Demos (both Lisp and Python)‏ • Design • Issues and Future Work

  3. Why has it taken so long? • Lisp is symbolic • Lisp is dynamic • Lisp has hooks • Debuggers don't tend to step through macros

  4. Why Source Debugging Now? • Increasing needs • Compiled functions are getting more complex • More macro usage • Better compilation • More attention to optimization • New capabilities • Macros can now be stepped through

  5. Design Requirements • Works by annotation, not by re-coding and/or recompilation • Annotations must be lazy-loaded • Similar operation between compiled, byte-compiled, interpreted code • Language agnostic • Command Line and GUI compatible

  6. History of Allegro CL Source Debugging Effort • 1998: Promise made • 1999: First debugger paper (show demo)ftp://ftp.franz.com/pub/duane/break.ps • 2007: Resurgence of effort including CLPython • 2009: Command line version • ????: GUI versions

  7. Lisp Demos • ltest.cl • Zoom on error demo • Coverage demo • Debugging the compiler

  8. CLPython Demos • Willem will demo: • setting breakpoints • stepping • printing stack trace • debugging the CLPython compiler

  9. Breakpointing Design Outline • Instruction level (break.ps)‏ • Source mappings • Language Personalities • Backends

  10. Instruction level design • Review break.ps, Figures 1-4

  11. Source Mappings • Breakpoints (records) pre-built • Accessed by index • Level 0 records will point to source text • New slots in breakpoint structures • Language-dependent • Usually includes source form or string • Show dump-lisp-source for ltest

  12. Language Personalities • Language structure, mostly with functions • Contents: • Name: currently :asm, :lisp, or :python • predicate: Function to test for appropriate debug info • find-pc: Function to • print-pc: Function to print line/form • prompt-loop: Function to prompt the user • set-next: Function to set next breakpoints • list-exits: Function to list possible slide directions • slide: Function to slide around in breakpoint set

  13. Back-ends • Currently very primitive • Structure has two slots • a format function • a prompt-loop function • Show back-end for coverage code

  14. lisp-breakpoint pseudo-code (defun sys::lisp-breakpoint (func pc)‏ (uninstall-breakpoints)‏ (let* ((bpt (get-breakpoint func pc))‏ (ratchet (breakpoint-is-ratchet bpt)))‏ (cond ((and bpt (not ratchet))‏ (setq *slide-point* bpt)‏ (let* ((lang (breakpoint-language bpt))‏ (command (call-prompt-loop language bpt)))‏ (delete-temp-breakpoints)‏ (call-set-next language bpt command)))‏ (ratchet (delete-temp-breakpoints)))‏ (install-breakpoints)))‏

  15. CLPython Personality • Willem will discuss: • Mapping from Python source code to asm location: • Python Parser: mapping Python source to Lisp forms • Allegro CL: mapping Lisp forms to asm offsets • Python ldb language and backend based on that mapping • Source forms at finer granularity than line-level

  16. Lisp Issues • Variables not yet propagated through macros • Local variable locations may not be saved to stack • Multiprocessing critical section issues

  17. Variable Propagation through macros (defmacro foo (x y)‏ (let ((x1 (gensym))‏ (y1 (gensym)))‏ `(let ((,x1 ,x)‏ (,y1 ,y))‏ ...)))‏ • Variables will be displayed as gensyms in compiled code • No references to original x and y variables

  18. Local Variable Locations (let ((x (foo))‏ (y (bar)))‏ (bas x y))‏ • X will likely be on the stack soon after call to (foo)‏ • Y might never be forced to the stack • Debugger must allow for non-stack variables

  19. Multiprocessing Issues • Per-thread, or global? • Have lisp-breakpoint decide • Setup separate code-vectors per-thread • Lock out critical sections, or allow lisp death?

  20. CLPython Issues • Willem will discuss: • proof of concept • mappings: Python code -> Lisp code -> asm code incomplete/incorrect • stepping “into” Python forms is buggy (crashing)‏ • stack trace handling of non-compiled functions

  21. Other Future Work (Lisp)‏ • GUIs • CG • Emacs/Lisp Interface (ELI)‏ • Slime • True back-stepping • Handle state at various levels • provide user interface for extending undo-ability • Other Language personalities • Lisp DSLs • Loop • CL<any-language>? CLJava? CL/XML? ...

  22. Other Future Work (CLPython)‏ • More debugger commands • run Python code within a stack frame • special stack trace showing Python and Lisp frames combined, to debug CLPython itself • robustly handling source module modifications • Year ????: a complete Lisp-based Python compiler and IDE, based on CLPython and Slime

  23. Thank You.

More Related