Any good debuggers for Python? (was Re: using python debugger (pdb) inside emacs debugger mode ...)

[Ovidiu Predescu]

On Sat, 18 Sep 1999 20:52:20 +0200 (MET DST), Charles G Waldman <cgw at fnal.gov> 
wrote:

> Ovidiu Predescu writes:
> 
>  > I would still like to have a pdb-mode for source files, similar
>  > with gdb-mode
> 
> Could you elaborate a little bit on what you would like this mode to
> do?  Do you mean being able to click on expressions in the source
> buffer and print out their values, etc?  This might not be too hard to
> add to pdb.el without needing any big modifications to pdb.py, in
> particular I'm not sure that gdb annotations are required.  Or are you 
> talking about something else?

Yes, I was referring to this ability. In Xemacs, there are two different modes
that support debugging, one is implemented in gud.el and another one is gdb.el.
The gdbsrc mode that implements the "click on expression and print" is
implemented as an extension to gdb.el. On the other hand, pdb.el is implemented
as an extension to gud.el, that doesn't have this functionality. I don't know
how hard will be to extend gud.el to have this functionality.

Regarding the gdb annotations, I just looked on gdb.el in the Xemacs sources
and it looks like you're right, they don't seem to be used in gdb.el. However
gud.el does seem to use annotations for keeping the internal emacs buffers in
sync with gdb's location.

>  > A better thing might be to have gdb support debugging Python programs, just
>  > like it supports the other languages, but this is a different topic.
> 
> It's probably safe to say that this will never happen, support for
> Python debugging would be just *too* different than the languages GDB
> already supports.  But what would be good would be to have a Python
> debugger that presents the identical interface as GDB, so that it
> could be used in contexts where GDB is used (like XEmacs, and the
> other various GUI front-ends to GDB that are out there).... This is
> something I'd like to work on but quite honestly I haven't had the
> time recently, possibly in a few months when I finish up some current
> projects, I'll be able to get back to my "PyGDB" project.

GDB indeed doesn't have support for debugging interpreted languages at this
time, but this doesn't mean it cannot support this. I believe this can be
achieved pretty easily by having the GDB process invoke the Python debugger in
the target program.

I didn't figure out exactly all the details, but the basic idea is to use GDB
to handle all the interaction with the user instead of pdb. pdb becomes only a
debugging engine that's loaded in a Python program and knows how to setup
breakpoints, continue the program etc. All these operations are published in a
simple Python API that could be called from GDB.

Pdb needs to be extended to call some C functions in the Python interpreter
when it reaches certain states. For example, each time the pdb engine hits a
Python breakpoint in the target program, it calls a C function. GDB has a
breakpoint setup in this function and it knows that whenever this breakpoint is
hit, the pdb debugger in the target process reached a breakpoint. At this point
the control is returned back to GDB. When GDB wants to continue the program it
calls pdb in the target program and changes its state. Then GDB simply
continues the program, at which point pdb discovers that its internal state has
changed and proceeds accordingly.

What I'm working on right now is adding scripting language support to GDB so
that this kind of functionality could be implemented in GDB using an
interpreted language and not C. The language I'm embedding is surprise, Python
;-). This work is part of the WDB project here, at HP, but all the work we're
doing is going back in the FSF main tree. For more information on WDB, take a
look at:

http://www.hp.com/esy/lang/tools/Debuggers/index.html


Greetings,
Ovidiu

--
Ovidiu Predescu <ovidiu at cup.hp.com>
http://andromeda.cup.hp.com/  (inside HP's firewall only)
http://www.geocities.com/SiliconValley/Monitor/7464/