Re: [Announce] Second Alpha release of a Lua debugger

[Rici Lake <lua@...>]

Steve Heller wrote:
> On Sun, 15 Apr 2007 22:33:53 -0500, Rici Lake <lua@ricilake.net>
> wrote:
>
> > Rici Lake wrote:
> > > In a spurt of energy over Easter, I wrote a simple console-based 
> > > debugger for Lua, which I hope will prove useful. I've set up a
> > > CVSTrac (temporarily) at http://primero.ricilake.net:8008/ldb/index
> > I've now done a partial implementation of breakpoints (no conditional
> > breakpoints nor tracepoints, although I should be able to add those
> > fairly soon.)
> >
> > You can examine files in the CVS, or get the complete tarball from:
> > http://primero.ricilake.net/lua/ldb-25.tar.gz  There have been some
> > changes from the previous version; in particular, the breakpoint
> > support is a separate file.
> >
> > Comments and suggestions are welcome.
>
> Looks very nice for an alpha product. I do have a couple of questions,
> though:
>
> 1. I think line 35 of ldb-break.lua should read:
>
> "local breakcalls, breakrets"
>
> rather than
>
> "local breakcall, breakret"
>
> as the latter causes the code to fail the "strict" check during
> compilation.

Quite right, thank you. It's been fixed in CVS and will be in tomorrow's
tarball.

> 2. How do I actually use breakpoints? I don't seem to be able to get
> them to do anything. I can set them, but then if I do a "c" to
> continue, they seem to be ignored. Also, if I call "ldb()" to invoke
> the debugger, then try to do "s" or "n", I get a message "Not inside
> breakpoint". Do you have an example of how to use them?

Yeah, I should have explained that better. The documentation lags the
code a bit, but I'm trying to finish it all up in my spare time this
week.

Basically, the easiest way to use breakpoints is to start the program
you're debugging with the ldb script included in the distro. You just
do:
  ldb myprog.lua #arguments if any

and it should stop at the first line in myprog.lua. You're then inside
a breakpoint, and you can use them freely.

The other way of doing it is to start lua up, load up ldb and ldb-break,
and manually set a breakpoint. The file you're debugging doesn't
need to be loaded yet in this case, since breakpoints are identified
by filename. But the filename has to match character for character;
ldb includes no file handling code, so it can't tell that ./foo.lua
and foo.lua are the same file.

Once you've done that, you can quit ldb and start the file up with
dofile or require or whatever (but in the case of require, you'll
definitely have to watch out for the way the filename is entered.)

I'd like to make it less awkward; I'm still playing with some ideas.

The reason that it won't let you single step unless you're inside
a breakpoint is that it needs to be able to work without Lua hooks
going off. When you're inside a hook handler, hooks are disabled,
so it can work freely knowing that hooks will be re-enabled when
it returns to the program. If it wasn't called from a hook handler,
and it sets the hook handler, the hook will go off before it returns
to the program.

I could have gotten around this by running the program in a
coroutine, which probably would have been a lot easier. However,
ldb was primarily intended for debugging C modules and embedded
Lua, and I did not want to create new coroutines inside an
environment which already used coroutines itself.