Medic: Metaprogramming and Trace-Oriented Debugging Xiangqi Li Matthew Flatt University of Utah, USA University of Utah, USA [email protected] mfl[email protected] Abstract ining specific behaviors of programs. However, trace debug- Modern programmers enjoy a wealth of high-level and ging in practice has changed little since the early days of pro- graphical tools for understanding and debugging programs. gramming. Programmers continue to work with text-based, Nevertheless, programmers often resort to the simple and linear traces, while a variety of data visualizations are possi- the time-honored technique of inserting print statements ble, and textual output is awkward for representing tree and into programs to reveal progress and to expose intermedi- graph-structured relationships among data. Traditional trace ate values. This trace debugging (a.k.a. printf debugging) debugging is good for generating data with local (to the im- technique persists because it has many advantages. Tradi- plementation) filters, but it offers little support for process- tional trace debugging also has several drawbacks, including ing the output data in a non-local way. the need to modify the source program and the need for ad- The necessity of modifying a program’s source to insert ditional tools when trace output becomes too voluminous. print commands creates other obstacles. Debugging code Medic, our new debugging and program-exploration tool is mingled with the original code, which obscures the orig- for Racket, augments the traditional examination of control inal code during debugging; after debugging is complete, and state with output processing, metaprogramming, and vi- further work is needed to recover the clear, original source. sualization features. Medic allows programmers to leverage Removing debugging code wholesale, meanwhile, discards the benefits of trace debugging while addressing many of its work that is useful for understanding or further debugging drawbacks. of the code in the future. Finally, code written for debugging purposes rarely enjoys the organizational and reuse proper- Categories and Subject Descriptors D.3.3 [Programming ties of most other code, because the debugging code must be Languages]: Language Constructs and Features tightly bound to the details of the main implementation. Keywords Metaprogramming, trace debugging, visualiza- Medic addresses these two sets of trace-debugging prob- tion lems through a pair of complementary strategies. The first strategy is to separate debugging code from the main im- 1. Introduction plementation through a metaprogramming language that can weave—in the sense of aspect-oriented programming (Kicza- Many different techniques can help a programmer find bugs les et al. 1997)—print commands into the main program. or understand the execution of a program. A programmer The second strategy is to provide a set of print replace- can set breakpoints, step through the program, check the ments and post-processing tools that better organize and call stack and values of local variables, and add print present the printed output. While the code-weaving and statements to produce traces of program states and values. data-visualization features of Medic are not new in iso- That last technique of adding print statements is called lation (Czyz and Jayaraman 2007; Lienhard et al. 2009; trace debugging or printf debugging. Stamey et al. 2005; Usui and Chiba 2005), Medic demon- Trace debugging offers many benefits compared to other strates how to combine those pieces into a more effective techniques. Print statements are lightweight, and they are debugging tool. convenient for exposing specific values of interest or exam- Medic’s language for describing and integrating print statements into a program is similar to AOP systems and the advising facility in PILOT (Teitelman 1966), but tailored to the specific needs of trace debugging. Similarly, with spe- cific data-visualization techniques in mind, Medic supports This is the author’s version of the work. It is posted here for your personal use. Not for four kinds of traces: redistribution. The definitive version was published in the following publication: FPW’15, October 26, 2015, Pittsburgh, PA, USA c 2015 ACM. 978-1-4503-3905-6/15/10... • Log traces: Similar to traditional print statements, http://dx.doi.org/10.1145/2846656.2846658 log traces are linear and text-based, but they include 7 conveniences for recording the source context, function is declared by (layer layer-id layer-form ...) with an optional behavior, and filterable layers in trace output. #:enable specification that can enable or disable a layer’s • Graph traces: A tracing graph presents a new means of output. Within a layer, we can enable abstraction and ab- recording relationships among traced values, ultimately straction and parameterization of a fragment of code, which allowing programmers to visually understand the spatial can be either run-time code or a fragment of metaprogram- relationship between trace elements. Graph traces are ming specification. complementary to text-based traces, which cannot easily Besides allowing access to elements of a source pro- represent connective relationships. gram in debugging instrumentation, Medic reflects addi- tional information for use in certain debugging forms. The • Aggregate traces: Aggregate traces enable grouping function-name variable is bound to the enclosing function multiple trace elements together. Programmers can scrub or a function being called. For example, instead of te- through the accumulated steps of data—seeing one step diously annotating each function f, g, etc., with (print of data at one time—and enable data comparisons by "f function entered"), (print "g function specifying the two comparing data points. entered"), etc., Medic lets a programmer write • Timeline traces: Each individual trace element is rep- [each-function [on-entry @log{@function-name function entered}]] resented by a timeline, which shows an overview of the evolution of values over time. A timeline slider enables The string-template notation here using @ is an alternate step-wise exploration in an abstract execution time view representation of an S-expression, and is the same as used or a clock-based view, and a tooltip window allows dis- for Scribble (Barzilay 2009; Flatt et al. 2009). Through playing an individual value. (with-behavior f template), a programmer can define the logging behavior, represented by template, of the f function. In the remainder of this paper, we describe the design of Inside template, we allow the @arg and @ret escapes to access Medic’s trace-oriented metaprogramming language and its a function’s argument and return value. four kinds of traces and their visualizations. In each section on a specific tracing facility, we show how the tracing facility 3. Trace Debugging is useful for finding bugs and understanding program behav- ior. Finally we discuss the implementation of the debugging Medic supports four kinds of tracing (i.e., variants of print) system, including the interpretation of the Medic language, with associated visualizations, each of which is useful for the weaving of debugging code, and the generation and rep- different debugging tasks. All traces are directed to an in- resentation of traces. teractive graphical user interface, a trace browser. The trace browser consists of four panes that correspond to the four 2. A Trace-Oriented Metaprogramming kinds of traces: a Log pane, a Graph pane, an Aggregate Language pane, and a Timeline pane. The syntax and semantics of each tracing form are as Medic’s metaprogramming facilities start with the ability to follows: describe the placement of debugging instructions. Program- mers must specify the locations in the source program where • Log forms. (log e), (log form v ...),@log the debugging instructions are added. We provide three cat- {template}: Add a log entry in the Log pane. For egories of scope specification of locations: module-level the second log form, where form is a string containing „ (through the (in #:module module-name match-form ...) form), as, log substitutes the value from the vs correspond- „ function-level (through the each-function and (f ...) forms), ing to the positions of as. The last log form allows the and expression-level (through the at form). use of @expr inside template. After the scope of location is identified in the source pro- • Graph forms. (node v [node-label color]), gram, debugging code can be inserted either on entry to the (edge from to [edge-label color from- identified code or on exit using the [on-entry source-expr ...] label to-label]): The node form creates a node or [on-exit source-expr ...] form. While some AOP systems associated with v in the graph visualization, and edge constrain inserted code so that it preserves modularity and creates an edge between the node associated with from encapsulation properties of the original program, Medic im- and the node associated with to. The square brackets poses no constraints, as is appropriate for debugging pur- specify optional arguments. When there exists no ex- poses. Medic thus allows an inserted form to access any plicit node creation from from or to, edge creates a identifier that is visible in the source program at the inser- corresponding node. tion point. • An aggregate form. (aggregate v ...): Add an Medic also provides a means of modularity and abstrac- aggregate entry in the Aggregate pane. tion. A Medic program consists of different layers, where a layer modularizes debugging code for a