From: Rocky Bernstein Date: 2010-08-03T00:16:28+09:00 Subject: [ruby-core:31596] RFC: Patches for Ruby 1.9 runtime for debuggers, profilers, and beyond --000e0cd2281e23d7f5048cd8af22 Content-Type: text/plain; charset=ISO-8859-1 I'd like to offer for public review of some patches for the Ruby 1.9 run-time environment. The patches attempt to support better run-time introspection, especially of VM instruction sequences, and execution tracing; they promote better support for writing tools like debuggers or profilers. I use these changes to Ruby in an experimental C extension which provides a runtime call-stack object (http://github.com/rocky/rb-threadframe). In turn, that extension is used in an experimental debugger ( http://github.com/rocky/rbdbgr). The patches come in 3 variations. 1. A single patch file for the trunk (1.9.3), http://github.com/rocky/rb-threadframe/blob/master/patches/ruby-trunk-combined.patch 2. The above broken out into 14 individual patches. There are 15, but the last one, 14-eval-iseq-name.patch is not currently used. 3. A single patch file for 1.9.2 rc2. This is analogous to 1. The patches are a bit too large to post here, but you can find them in the threadframe project: http://github.com/rocky/rb-threadframe/tree/master/patches. Each of the 14 separate patches has text at the beginning that describes what the patch does. A synopsis of the patches is given below. 0. Changes to allow a C extension to get access to some Ruby methods and fields defined in vm_core.h. 1. Fixes rb_vm_get_sourceline() so it returns the correct line number when the passed a VM PC with value 0. 2. Adds the ability to set tracing on or off per call frame. 3. Add more access to VM opcodes and finer control of VM disassembly. 4. Adds access to instruction sequences via SCRIPT_ISEQS__ and ISEQS__. This mechanism is similar to SCRIPT_LINES__ 5. Allows an extension to create an RubyVM::InstructionSequence object from an rb_seq_t pointer. Useful in adding Method#iseq and Proc#iseq 6. Adds the ability to get the number of parameters passed to a C function. It is like "arity" but contains the *actual* number of parameters passed. 7. Support for fast breakpoints. Used in the experimental 1.9 debugger. 8. Provides a way to get the exception object in a trace hook on a "raise" event callback. 9. Adds an optional trace masks trace hooks, and chaining trace hooks for threads. Adjusts the location slightly in C-function callbacks for calls and returns so they have access to the call stack. Allows a hook to change the return value on a C return. 10. Changes the instruction-sequence name of the top-most instruction sequence to something less generic, e.g. vs. 11. Adds RubyVM::InstructionSequence#arity and allows a C extension to return binding thread- and control-frame parameters. Used in rb-threadframe to provide RubyVM::ThreadFrame#binding. 12. Adds a new trace event mask to provide the ability to step VM instructions 13. Keeps a trace hook which raises an exception in fielding a C return from looping infinitely. I look forward to hearing your comments and suggestions. Thanks. --000e0cd2281e23d7f5048cd8af22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd like to offer for public review of some patches for the Ruby 1.9 ru= n-time environment. The patches attempt to support better run-time introspe= ction, especially of VM instruction sequences, and execution tracing; they = promote better support for writing tools like debuggers or profilers.

I use these changes to Ruby in an experimental C extension which provid= es a runtime call-stack object (http://github.com/rocky/rb-threadframe). In turn, that extensio= n is used in an experimental debugger (http://github.com/rocky/rbdbgr).

The patches come in 3 variations.

=A0 1. A single patch file fo= r the trunk (1.9.3), http://github.com/rocky/rb-threa= dframe/blob/master/patches/ruby-trunk-combined.patch

=A0 2. The above broken out into 14 individual patches. There are 15, b= ut the last one, 14-eval-iseq-name.patch is not currently used.

=A0 = 3. A single patch file for 1.9.2 rc2. This is analogous to 1.

The pa= tches are a bit too large to post here, but you can find them in the thread= frame project: http://github.com/rocky/rb-threadframe/tree/master/patches. = Each of the 14 separate patches has text at the beginning that describes wh= at the patch does.

A synopsis of the patches is given below.

0. Changes to allow a = C extension to get access to some Ruby methods and fields defined in vm_cor= e.h.
1. Fixes rb_vm_get_sourceline() so it returns the correct line numb= er when the passed a VM PC with value 0.
2. Adds the ability to set tracing on or off per call frame.
3. Add more= access to VM opcodes and finer control of VM disassembly.
4. Adds acces= s to instruction sequences via=A0 SCRIPT_ISEQS__ and ISEQS__. This mechanis= m is similar to SCRIPT_LINES__
5. Allows an extension to create an RubyVM::InstructionSequence object from= an rb_seq_t pointer. Useful in adding Method#iseq and Proc#iseq
6. Adds= the ability to get the number of parameters passed to a C function. It is = like "arity" but contains the *actual* number of parameters passe= d.
7. Support for fast breakpoints. Used in the experimental 1.9 debugger.
= 8. Provides a way to get the exception object in a trace hook on a "ra= ise" event callback.
9. Adds an optional trace masks trace hooks, a= nd chaining trace hooks for threads. Adjusts the location slightly in C-fun= ction callbacks for calls and returns so they have access to the call stack= . Allows a hook to change the return value on a C return.
10. Changes the instruction-sequence name of the top-most instruction seque= nce to something less generic, e.g.=A0 <top /tmp/ruby-program.rb> vs.= <top (required)>
11. Adds RubyVM::InstructionSequence#arity and = allows a C extension to return binding thread- and control-frame parameters= . Used in rb-threadframe to provide RubyVM::ThreadFrame#binding.
12. Adds a new trace event mask to provide the ability to step VM instructi= ons
13. Keeps a trace hook which raises an exception in fielding a C ret= urn from looping infinitely.

I look forward to hearing your comments= and suggestions.

Thanks.
--000e0cd2281e23d7f5048cd8af22--