 |
lua-l archive |
|
|
||
|
|
A somewhat late reply since I mostly don't follow this list these days.
> I've had a bunch of situations where it was useful to get the current > instruction number (not just the current line number) from debug.getinfo...
> (1) Is there anyone else who'd find that useful / is already patching > their local Lua to add that? Yes. The version of Lua various projects at Adobe use has a patch to allow checking the current opcode and it has been super useful and
is quite easy to do. It also has a 'basepc' which is essentially an ID for
function in a chunk based on a depth first traversal of the proto hierarchy
adding up all the opcodes.
We use those for generating usable* tracebacks from builds with compiled Lua (no line number debug info) and sometimes with other tools as
well (our sampling profiler** and code coverage mechanisms can
operate on stripped code as well). It was also handy for a special
high performance coverage mechanism that used self-clearing
breakpoints*** to gather opcode resolution coverage (so it could see
which branches are taken, not just line hits) with very low overhead.
That said, we've never bothered (for various reasons) with Lua versions past 5.1, so haven't bothered to push for any of those
changes to be adopted into Lua itself.
DT
* That is, we can symbolicate a traceback to turn it back into lines
of code and source file names.
** the sampling profiler does not use the line or instruction hook
because the overhead of running that way severely distorts the
results, which defeats the purpose of using a time profiler
*** our breakpoints don't use the line/count hooks either for the
same reason: way too slow in a largish codebase, so they have
no overhead until they are hit
|