claims of python unit test un-debugability considered somewhat exaggerated

[David Malcolm]

On Mon, 2013-04-08 at 11:32 -0600, Tom Tromey wrote:
> >>>>> "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.

FWIW I have a (stalled) upstream CPython patch that adds a
sys._breakpoint() hook here:
http://bugs.python.org/issue9635