[ANN] Scite-debug 0.9 Beta

["steve donovan" <steve.j.donovan@...>]

Hi all,

http://scitedebug.luaforge.net/

http://luaforge.net/frs/?group_id=327

There are some notes at:

http://lua-users.org/wiki/SciteDebug

The big feature of this release is integrated C/Lua debugging. In
particular, it is possible to single-step from Lua code to C extension
code.  To do this, scite-debug runs the clidebug Lua debugger _within_
a GDB session - this version of clidebug has a 'gdb mode' where it
understands a subset of GDB commands and generates appropriate -f
style file:line breaks.  When clidebug detects that we are entering a
C function in the 'call' event, it uses a small extension to supply it
with the actual C address, and calls a convenience C function with a
predefined breakpoint. The luagdb handler then picks up this address
and executes an 'info line' to find out if the function has debugging
symbols; if so it sets a temporary breakpoint. Either way, it then
sends 'continue' to GDB.

The other C/Lua scenario is where the host program has embedded Lua.
I've successfully debugged SciTE Lua on both Windows and GTK
platforms.

This stunt requires access to some internal Lua structures; I could
not find a public API method to do this (see dbgl.c in the
distribution; I also quote the relevant code in the wiki page.).  But
no patches required!

It also relies on GDB handling pending breakpoints, so if you're using
the old mingw GDB (version 5!), get a fresh one. (Keep the old one
around, because the new one is still a little flakey in places.)

It is in fact possible to debug Lua and extensions using a non-debug
version of Lua, which actually can be convenient. Otherwise, you are
going to single-step into every print call ;)  Obviously a mechansim
to exclude some files (or directories) would be useful here.

Clidebug itself has been optimized, but to get it any faster I'm going
to need to bite the bullet and go for a C-based debugger.

Give it a whack; some parts are still brittle, but I'm interested in
where it breaks!

steve d.