[issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks

[Dave Malcolm]

Dave Malcolm  added the comment:

On Fri, 2018-02-23 at 00:16 +, Cheryl Sabella wrote:
> Cheryl Sabella  added the comment:
> 
> Did PEP553 make this issue obsolete?

I *think* they have slightly different scope: if I'm reading it right,
PEP553 is about injecting a breakpoint into the Python debugger.  This
proposal was about injecting a lower-level breakpoint for debugging
CPython itself (for e.g. gdb to handle).

The idea was to make it easier to, say, step through a particular
CPython construct at the C level by injecting a breakpoint right before
it:

def test_something():
  # lots of setup
  sys.c_level_breakpoint()
  # whatever comes next

so that sys.c_level_breakpoint drops you into, say, gdb, and from there
you can step through the following Python code at the C level, without
having to express stepping through all the setup at the C/gdb level.

Hope that makes sense.

That said, I'm full-time on gcc these days, and unlikely to pursue this
from the CPython side.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks

[Cheryl Sabella]

Cheryl Sabella  added the comment:

Did PEP553 make this issue obsolete?

--
nosy: +csabella

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks

[STINNER Victor]

STINNER Victor added the comment:

 I thought about it making it METH_O instead (to make it easier to
 look at a single object), but then you'd be forced to pass an object
 in when using it, I think (though None should work).

I don't like this API. I really prefer METH_O because it is already very 
difficult to dump a Python object in a debugger (especially with gdb macros). 
Why not using two functions? One without argument, One with an argument.

The sys module is maybe not the right place for such low level function. You 
may create a new module with a name starting with _ (ex: _python_dbg). I'm 
quite sure that you will find other nice functions to add if you have a module 
dedicated to debugging :-)

If you don't want to create a new module, faulthandler might be used to add new 
debug functions.

It's maybe unrelated, but Brian Curtin also created a module to help debugging 
with Visual Studio:
https://bitbucket.org/briancurtin/minidumper/

We may use the same module for all debugging functions? (I suppose that Brian 
Curtin wants to integrate its minidumper into Python 3.4.)

Example:

 * faulthandler._breakpoint()
 * faulthandler._inspect(obj) # breakpoint with an object
 * faulthandler.enable_minidumper(...)
 * faulthandler.disable_minidumper(...)

--

For Power PC, the machine code to generate a breakpoint is 0x0cc0. The 
instruction looks to be called twllei. Something like: twllei 
reg_ZERO,trap_Cerror. Hum, it looks like there is family of instructions 
related to trap: all TW* instructions (twle, twlt, twge, ...).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9635
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks

[Dave Malcolm]

Dave Malcolm added the comment:

On Tue, 2010-11-02 at 17:25 +, Antoine Pitrou wrote:
 Antoine Pitrou pit...@free.fr added the comment:
 
 I would rename Py_BREAKPOINT to _Py_BREAKPOINT since we don't really want to 
 support this. Also, why do you allow any arguments to sys._breakpoint()?
Agreed about _Py_BREAKPOINT.

The reason for allowing arguments to sys._breakpoint() is so that the
developer can pass in arbitrary objects (or collections of objects),
which can then be easily inspected from the debugger.  Does that seem
sane?

Maybe the docs should read:

--
This may be of use when tracking down bugs: the breakpoint can be
guarded by Python-level conditionals, and supply Python-generated data::

   if foo and bar and not baz:
   sys._breakpoint(some_func(foo, bar, baz))

In the above example, if the given python conditional holds (and no
exception is raised calling some_func), execution will halt under
the debugger within Python/sysmodule.c:sys_breakpoint, and the result of
some_func() will be inspectable in the debugger as
((PyTupleObject*)args)[0]

   static PyObject *
   sys_breakpoint(PyObject *self, PyObject *args)
   {
 _Py_BREAKPOINT();
 Py_RETURN_NONE;
   }

It can also be useful to call when debugging the CPython interpreter: if
you add a call to this function immediately before the code of interest,
you can step out of sys_breakpoint and then step through subsequent
execution.
--

I thought about it making it METH_O instead (to make it easier to look
at a single object), but then you'd be forced to pass an object in when
using it, I think (though None should work).

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9635
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks

[Dave Malcolm]

Dave Malcolm added the comment:

Note to self: a messy way of forcing gdb to do the equivalent of a breakpoint 
directly from Python is:
  os.kill(os.getpid(), signal.SIGTRAP)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9635
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks

[Dave Malcolm]

Changes by Dave Malcolm dmalc...@redhat.com:


--
nosy: +loewis

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9635
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks

[Antoine Pitrou]

Antoine Pitrou pit...@free.fr added the comment:

I would rename Py_BREAKPOINT to _Py_BREAKPOINT since we don't really want to 
support this. Also, why do you allow any arguments to sys._breakpoint()?

--
nosy: +pitrou

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9635
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks

[Dave Malcolm]

Dave Malcolm dmalc...@redhat.com added the comment:

I renamed it from sys.breakpoint to sys._breakpoint, since this is 
CPython-specific

--
title: Add Py_BREAKPOINT and sys.breakpoint hooks - Add Py_BREAKPOINT and 
sys._breakpoint hooks

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9635
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com