Re: Debugging luacode => efficient file name retrieval?

[Mike Pall <mikelu-0703@...>]

Hi,

Eike Decker wrote:
> > Use the function object as a key for a weak keyed table [...]
> 
> During development I tried it out, but it was still not satisfying :/ - but
> maybe I will try it again - my current approach is somehow not working
> properly.

I'm pretty sure this is fast enough and won't slow things down
that much. Just be very careful what you request with
lua_getinfo().

> The table approach is also quite slow if the function is created by
> an closure [...]

Well, only if you are creating (and calling!) closures at an
excessively high rate. In this case: don't do it, it's slow even
without debugging. ;-)

[ OTOH if you are willing to go _very_ deep into the internals
you could index the table with a Proto object. This is unique for
all closures created for it. There's no way to access or create
such an object right now, so it'll never surface. But the GC
knows about it and given the high orthogonality of the Lua core,
it _should_ just work (but don't take my word for it). ]

> In between I thought about this: How complicated would it be and how much
> performance would it drain to mask the compiled bytecode?

You could add a new VM breakpoint instruction. Replace any
regular instruction with it and store the original away. When the
breakpoint is executed, activate the hooks, replace the
instruction with the original (you can use the Bx operand for
indexing an internal array), decrement the PC and continue with
the VM loop.

You'd need to be careful with string.dump(), though (if you use
it). Other than that, I don't see a problem.

> And what would I need to consider for luajit? 

Well ... that's a different story. First you need to enable
debugging. This disables many optimizations and adds lots of
inline code for calling the hooks. Expect a serious slowdown.

And then ... of course the bytecode swapping trick doesn't work
here. Modifying the machine code on-the-fly is very tricky. Not
for the faint of heart.

> It would be really great if I could implement the debugger in a
> way that needs no additional resources...

Zero cost debugging is doable, sure. But it takes lots of work.
I suggest you try to implement my earlier proposal first. ;-)

Bye,
     Mike