tracing feature

Ruby debugger

set_trace_func

Rubinius

Rubinius compiles all Ruby code into instructions (op_codes) which the shotgun VM runs - currently with a op_code interpreter

all Ruby code into instructions (op_codes) which the shotgun VM runs - currently with a The full speed debugger functionality introduced a new instruction yield_debugger which - when executed - notifies the debugger thread on a defined debugging channel (Channels are a kind of pipe - i.e. data sent into it can be received on the other end).

channel (Channels are a kind of pipe - i.e. data sent into it can be received on the other end). It's possible to access the bytecode for a Method - actually it's trivial to do so. Here an example with String 's to_s method: m = "".method(:to_s) cm = b.compiled_method

# this yields an array of InstructionSet::Opcode objects cm.bytecodes.decode

for a Method - actually it's trivial to do so. Here an example with 's method: Various utility methods help map instruction offsets to line numbers, such as CompiledMethod 's first_ip_on_line etc.

setting a breakpoint

Take the Method object and get it's CompiledMethod object.

object. Figure out the position of the first instruction of the line of the breakpoint.

of the first of the line of the breakpoint. Exchange the instruction at this position with yield_debugger . The original instruction is kept around in a management data structure.

the at this position with . The original instruction is kept around in a management data structure. After the breakpoint is hit and the user continues execution, the original instruction is executed and then normal execution of the code resumes.

Adam Gardiner

step through code

sender

irb

shotgun/rubinius

Rubinius::VM::debugger

debugger

Ruby

yield_debugger

Debugger support is available in Ruby - a command line debugger has been shipped with it for a long time. Speed, however, was a problem. Ruby debuggers were implemented using Ruby's, i.e. a callback Block or function is called before a line of Ruby code is executed. This callback checked if the thread was suspended or if a breakpoint exists on this line.The defaultis implemented in Ruby, with a Ruby block simply set with. Faster versions of this approach were implemented in C ( ruby-debug Cylon debugger ) and Java ( jruby-debug ). However, no matter how fast the callback is executed, the problem of this solution remains: as soon as the debugger is started, every line of Ruby code incurs an overhead.An ideal solution for this has no overhead and simply suspends the thread when a breakpoint is hit. I.e. a breakpoint has no cost (in CPU cycles) until it's hit. This is the approach that Rubinius' full speed debugger uses - with "full speed" meaning that a program runs at it's normal speed even if it's being debugged.' full speed debugger is made possible by these characteristics:With this functionality in place,on a certain line of a method is simple:This functionality has been around for some time (see InfoQ's interview with Evan Phoenix on topics such as debugging ). However, the full speed debugger has now become usable for regular users with work from, who added a command line user interface for the Rubinius debugger and necessary commands. Not just that, he implemented the code that allows the user toline by line. This involved simply setting a breakpoint on the next line after the current one. Of course, this also needs to know if the current line is the last in a method - but this is also possible in Rubinius by getting a handle to the method that called the current one. The context object, i.e. the activation frame or stack frame of the method, has amethod doing just that.Using the debugger is simple. Once you have Rubinius (see how to check out and compile Rubinius ), startby running:Then execute this:(Note: just typingalso works at the moment). This will put you in the debugger's text interface - available commands can be seen with the "?" command, and include managing breakpoints and features like looking at the op_codes and the Ruby source of methods among others.The full speed debugger gives Rubinius a big edge versus Ruby implementations that need to rely on tracing based debuggers (no matter how fast these implementations are). It's also important to note: the complete debugger functionality was written in- with the exception of the handful of lines of C code for theinstruction.Have you tried Rubinius yet? Do you have ideas what you could do with Rubinius' transparency and accessible internals, i.e. accessing and modifying bytecode at runtime, inspecting the call stack etc.?Also: check out InfoQ's previous coverage of Rubinius