claims of python unit test un-debugability considered somewhat exaggerated

[Tom Tromey]

>>>>> "Michael" == Michael Stahl <mstahl at redhat.com> writes:

CCing David Malcolm.

Michael> (gdb) py-bt

I just wanted to mention here that Phil Muldoon is working on a "frame
filter" patch series that is basically "pretty printing for stack
frames".  With this in place you'll no longer need a special command --
with appropriate support from Python, you'll be able to see interpreted
frames interleaved with the low-level C frames.

This series is nearing final review now and should appear in gdb 7.7,
later this year.

I think we're planning to rewrite the existing "py-bt" code into frame
filter form ourselves.

Michael> unfortunately one thing that i haven't found how to do is setting a
Michael> breakpoint in the python code from gdb... the best i've found is a lame
Michael> workaround of inserting a statement into the python code to send
Michael> yourself a signal, which is, well, a lame workaround:

>> os.kill(os.getpid(), signal.SIGUSR1)

Michael> i wonder if it would be possible to easily add something to gdb to make
Michael> the python debugging a bit more seamless?

Eventually we'd like to have more full support for "mixed" interpreter
and C debugging.  However this is a ways off.

Meanwhile, you can do it, if you know some details about the interpreter
implementation.  It is just a question of setting a breakpoint at the
right spot in the C code, with the right condition so that it only fires
for your particular bit of code.  Maybe David can say how.  Perhaps the
"function__entry" SDT probe point is apropos.

Tom