[issue29400] Instruction level tracing via sys.settrace

[Xavier de Gaye]

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 instruction tracing remains an opt-in 
feature. As for this suggestion, I am not sure it is useful for debuggers based 
on the bdb module as trace_dispatch() (the bdb trace function) receives 
notification of the trace event type as the 'event' argument.

--

___
Python tracker 

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

[issue29400] Instruction level tracing via sys.settrace

[STINNER Victor]

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 

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

[issue29400] Instruction level tracing via sys.settrace

[George King]

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 

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

[issue29400] Instruction level tracing via sys.settrace

[George King]

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 exception handling works at the bytecode level.

--
Added file: http://bugs.python.org/file46486/inst-trace-demo.py

___
Python tracker 

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

[issue29400] Instruction level tracing via sys.settrace

[George King]

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 tracers/debuggers would not have set trace_instructions, so they 
would not receive any 'instruction' events, and should not suffer.

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.

--

___
Python tracker 

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

[issue29400] Instruction level tracing via sys.settrace

[STINNER Victor]

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 PyTrace_LINE as it does now".

Hum, there are two things:

* attached patch adds an else to the C maybe_call_line_trace(): I don't think 
that it's possible to notice the overhead in a debugger implemented in pure 
Python. If you are concerned by the change, we need a micro-benchmark.

* existing debuggers may have to be extended to support PyTrace_INSTRUCTION and 
so may be slowed down. Maybe I misunderstood what you wrote? For me, it's an 
opt-in feature: you must call sys.settraceinstr() instead of sys.settrace(), 
otherwise you don't get PyTrace_INSTRUCTION events. From the user point of 
view, I expect that the debugger starts at LINE level, but only switch to 
instruction level when I explicitly ask it to do so.

--

___
Python tracker 

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

[issue29400] Instruction level tracing via sys.settrace

[Xavier de Gaye]

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 as this would happen if George 
does "Remove the `else` to always trace with PyTrace_INSTRUCTION, rather than 
as an alternate to PyTrace_LINE as it does now".
I understand that this was a suggestion :)

--

___
Python tracker 

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

[issue29400] Instruction level tracing via sys.settrace

[STINNER Victor]

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 trace_instructions parameter to 
keyword only: sys.settrace(func, True) raises a TypeError (I added an unit test 
for that).

About the API, I see an issue: the "old=sys.gettrace(); sys.settrace(old)" 
pattern doesn't work anymore, since old doesn't contain the trace_instructions 
flag :-/ So I suggest to add a new method and make it exclusive with 
sys.settrace(), sys.settraceinstr() / sys.gettraceinstr():

* sys.settrace() raises an exception of sys.gettraceinstr() is not None
* sys.settraceinstr() raises an exception of sys.gettrace() is not None

The sys module is a critical module, so the API should probably be discussed on 
python-dev (later?).

About performances: it's fine to add anything to maybe_call_line_trace(), it 
cannot impact performances when tracing is not used.

Can you please try to reimplement something like __lltrace__ on top of 
sys.settraceinstr()? It would be a nice example of the API, but also a good 
reason to add sys.settraceinstr().

See the issue #25571 "Improve the lltrace feature with the Py_Debug mode".

Currently, the __lltrace__ feature requires a Python compiled in debug mode, 
which is not convenient. Moreover, it requires to put a __ltrace__ variable in 
global variables.

The best would be able to add an instruction level debugger inside pdb! It 
would be a cool tool to learn Python and to play with the bytecode!

--
Added file: http://bugs.python.org/file46485/inst-tracing-2.diff

___
Python tracker 

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

[issue29400] Instruction level tracing via sys.settrace

[Xavier de Gaye]

Changes by Xavier de Gaye :


--
nosy: +xdegaye

___
Python tracker 

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

[issue29400] Instruction level tracing via sys.settrace

[George King]

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 

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

[issue29400] Instruction level tracing via sys.settrace

[Ammar Askar]

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 

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

[issue29400] Instruction level tracing via sys.settrace

[STINNER Victor]

STINNER Victor added the comment:

Can you please attach your patch?

--

___
Python tracker 

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

[issue29400] Instruction level tracing via sys.settrace

[George King]

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 simple.

http://github.com/gwk/cpython/tree/inst-tracing

The crucial detail in ceval is here:

@@ -4521,6 +4523,9 @@ maybe_call_line_trace(Py_tracefunc func, PyObject *obj,
 frame->f_lineno = line;
 result = call_trace(func, obj, tstate, frame, PyTrace_LINE, Py_None);
 }
+else if (tstate->inst_tracing) {
+result = call_trace(func, obj, tstate, frame, PyTrace_INSTRUCTION, 
Py_None);
+}

The call to maybe_call_line_trace is guarded by several checks, so I do not see 
how this would significantly impact performance, except for when tracing is 
enabled. I built python3.6 using clang -O3 -flto (I saw lots of test failures 
during the --with-optimizations PGO tests so I opted for a simpler build), with 
and without my patch. I then ran `python3 -m performance run --fast` and 
manually compared the results. The patched version was in most cases slightly 
slower but within the standard deviation of the normal version.

I would appreciate feedback before going any further with this. I looked at 
haypo's perf project but was unsure how to use it to run a more detailed 
comparison.

* First, will this feature be rejected on performance grounds or some other 
obvious reason?

* Second, does setting `tstate->inst_tracing` in PyEval_SetTraceInstructions 
require more elaborate guards similar to those in PyEval_SetTrace? I do not 
understand the intricacies of that function.

I am also curious about backwards compatibility. This adds an optional argument 
to settrace (haypo's recommendation) and some other things that appear to be 
under Py_LIMITED_API or internal (but I am not sure).
* Is a change like this eligible for 3.6.x or would it have to wait until 3.7?
* Would it be better to add a completely new function, e.g. 
sys.settrace_instructions instead of changing the signature of settrace?

Lastly, I have a few ideas for enhancing this patch that will require some more 
work on my end to verify their utility.
In particular:
* Remove the `else` to always trace with PyTrace_INSTRUCTION, rather than as an 
alternate to PyTrace_LINE as it does now.
* Pass the previous instruction offset as the trace function argument. This 
would give the tracer complete "edge" information. (In my coverage tool's trace 
function I track the previous edge as a nonlocal, but it would be better/faster 
to do it automatically in maybe_call_line_trace).
* Finally, if all of this works, it might also be useful (as a performance 
enhancement) to add a PyTrace_BRANCH option, which would omit runs of opcodes 
inbetween branches, as these edges tend not be be useful, and even 
counterproductive (at least for my use case). However it might be too tricky to 
get all the cases right.

--
components: Interpreter Core
messages: 286546
nosy: George.King, haypo
priority: normal
severity: normal
status: open
title: Instruction level tracing via sys.settrace
type: enhancement
versions: Python 3.6

___
Python tracker 

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