[issue29400] Instruction level tracing via sys.settrace

Xavier de Gaye added the comment: > The motivation for this suggestion was that for tracers that *are* interested > in instructions, it *might* be simpler to get two calls, one of 'line', and > one of 'instruction'. Maybe it's a bad idea though. Thanks for the clarification. It's ok if

[issue29400] Instruction level tracing via sys.settrace

STINNER Victor added the comment: Hum, I don't know well how Python tracing works, but if we had a new "instruction level debugging" feature, it must be an opt-in feature. Existing debuggers must not be flooded by such events. -- ___ Python tracker

[issue29400] Instruction level tracing via sys.settrace

George King added the comment: Thanks to both of you for your feedback. I will take a stab at updating the patch with Victor's suggestions as soon as I can. -- ___ Python tracker

[issue29400] Instruction level tracing via sys.settrace

George King added the comment: Attached is a demo of using the feature as a fancy replacement for __ltrace__. It demonstrates using a closure for the local trace function to track the previous offset, and prints the offset transitions as src -> dst pairs. This helped me learn a lot about how

[issue29400] Instruction level tracing via sys.settrace

George King added the comment: Xavier, this is a misunderstanding; sorry for not being more clear. When I said "remove the `else`", I was proposing this: + if (tstate->inst_tracing) { + result = call_trace(func, obj, tstate, frame, PyTrace_INSTRUCTION, Py_None); + } Line-oriented

[issue29400] Instruction level tracing via sys.settrace

STINNER Victor added the comment: > I do not agree, Python debuggers are already really really slow. They should > not have to process 'instruction' trace events as this would happen if George > does "Remove the `else` to always trace with PyTrace_INSTRUCTION, rather than > as an alternate to

[issue29400] Instruction level tracing via sys.settrace

Xavier de Gaye added the comment: > About performances: it's fine to add anything to maybe_call_line_trace(), it > cannot impact performances when tracing is not used. I do not agree, Python debuggers are already really really slow. They should not have to process 'instruction' trace events

[issue29400] Instruction level tracing via sys.settrace

STINNER Victor added the comment: inst-tracing-2.diff: * Rebased patch applied on Mercurial, I had to fix a conflict in sys_settrace() * I replaced your PyEval_SetTraceInstructions() function with a new private _PyEval_SetTraceEx() method * I changed sys.settrace() API to convert the

[issue29400] Instruction level tracing via sys.settrace

Changes by Xavier de Gaye : -- nosy: +xdegaye ___ Python tracker ___ ___ Python-bugs-list

[issue29400] Instruction level tracing via sys.settrace

George King added the comment: Here is the patch from git; if you need a patch for hg I can work on that tomorrow! -- keywords: +patch Added file: http://bugs.python.org/file46475/inst-tracing.diff ___ Python tracker

[issue29400] Instruction level tracing via sys.settrace

Ammar Askar added the comment: A git style patch can be found at https://github.com/gwk/cpython/commit/071d17cedfdf2db8b405aab5adabebe2ac5ef67b.patch -- nosy: +ammar2 ___ Python tracker

[issue29400] Instruction level tracing via sys.settrace

STINNER Victor added the comment: Can you please attach your patch? -- ___ Python tracker ___ ___

[issue29400] Instruction level tracing via sys.settrace

New submission from George King: I have recently put some effort into developing a code coverage tool that shows correct results for intraline branches. In order to get intraline trace data, I patched CPython, adding an optional "trace instructions" flag to sys.settrace. The patch is fairly