lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 


On 20.04.2012 20:20, Dan Tull wrote:

Thomas Jericke

In the linked patch a function has to be on the stack to be able to
install a breakpoint. I don't have this requirement. As I need to be
able to add a breakpoint to a "running" interpreter at any time the
approach in the linked patch will not work for me. Instead I have to
have a structure of all protos running in the interpreter (currently I
use a linked list) to find the proto of a given source name and line number.

FWIW, the full version does support applying breakpoints to a proto even
if if no live functions* exist that use it. That's the additional change to which
this remark refers:


== Disadvantages ==
- You have to be able to locate a reference to the function in which
   you want to set the breakpoint. We actually made another mod
   to make this faster and easier but that's a separate change.

(see: http://thread.gmane.org/gmane.comp.lang.lua.general/68867/focus=69271)
Ok then I have to compare my changes with those as well. Are you planning to release a patch for Lua 5.2? 

What we did sounds similar to your approach. It was added very shortly
after I generated the patch, but I never went back and updated it (mostly
because nobody came asking).

There's an extra API lua_setprotohook that allows us provide a callback.
We use that to keep an up to date structure with all the protos so they can
be patched or unpatched quickly without a function reference.
That sound very similar. I have added code to luaF_newproto and luaF_freeproto to keep track of all the protos that live inside the interpreter. 
I also added a callback to be able to trace the state of my breakpoints.


We've gotten a lot of benefit from having fast breakpoints. I've actually got
some ideas for using it for low overhead dtrace-like performance analysis and
fast code coverage, but haven't pursued those in earnest yet.

DT

* for example, if there's function exists returns closures, but it hasn't been
called at the time a breakpoint is set in it (or has been called, but all the results
were already garbage collected)
Adding breakpoint instructions was "must have" for our project, because the standard debuggers for Lua were just too slow (that means their impact on runtime was too heavy). 

--
Thomas