[issue29400] Add instruction level tracing via sys.settrace

[STINNER Victor]

Change by STINNER Victor :


--
resolution:  -> rejected

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[George King]

George King  added the comment:

Nick's implementation of f_trace_lines/f_trace_opcodes serves the same purpose 
as my proposal, and is a simpler solution so I'm abandoning this patch and 
working with that feature instead.

--
stage: test needed -> resolved
status: open -> closed

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-31344 and PR #3417:

New changeset 5a8516701f5140c8c989c40e261a4f4e20e8af86 by Nick Coghlan in 
branch 'master':
bpo-31344: Per-frame control of trace events (GH-3417)
https://github.com/python/cpython/commit/5a8516701f5140c8c989c40e261a4f4e20e8af86

--

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[Jakub Wilk]

Change by Jakub Wilk :


--
nosy: +jwilk

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[Fred L. Drake, Jr.]

Change by Fred L. Drake, Jr. :


--
nosy: +fdrake

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[STINNER Victor]

STINNER Victor  added the comment:

The main blocker question is the API change. I started a thread on python-dev 
to discuss it:
https://mail.python.org/pipermail/python-dev/2017-September/149632.html

--

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[George King]

Changes by George King :


--
pull_requests: +3278

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[George King]

George King added the comment:

Attached updated demo script.

--
Added file: http://bugs.python.org/file47107/settracestate-demo.py

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[George King]

George King added the comment:

(Also I did prototype instruction filtering but it had mild performance 
implications when tracing so I have shelved it for the moment.)

--

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[George King]

George King added the comment:

I've updated the patch and I think it's ready for a more serious review. A few 
notes:

* settracestate now takes a flag `trace_instructions`. This describes slightly 
better the behavior, which is that line events take precedence over 
instructions.

* the old gettrace now raises when `trace_instructions` was set, to prevent 
silent failure of the old idiom `saved = gettrace(); ... settrace(saved)`.

* gettracestate returns a dictionary, which can be passed to settracestate as 
kwargs. This allows for a replacement idiom `saved = gettracestate(); ... 
settracestate(**saved)` which should be forward-compatible with any flags we 
might add in the future.

The patch can be viewed here: 
https://github.com/python/cpython/compare/master...gwk:trace-inst

Let me know if I should open up an official PR. Also I just filled out the CLA.

--

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[George King]

George King added the comment:

After reviewing the thread, I'm reminded that the main design problem concerns 
preserving behavior of this idiom:
"old=sys.gettrace(); ...; sys.settrace(old)"

If we add more state, i.e. the `trace_instructions` bool, then the above idiom 
no longer correctly stores/reloads the full state.

Here are the options that I see:

1. New APIs:
* `gettrace() -> Callable # no change.`
* `settrace(tracefunc: Callable) -> None # no change.`
* `gettraceinst() -> Callable # new.`
* `settraceinst(tracefunc: Callable) -> None # new.`
Behavior:
* `settrace()` raises if `gettraceinst()` is not None.
* `settraceinst()` raises if `gettrace()` is not None.


2. Add keyword arg to `settrace`.
* `gettrace() -> Callable # no change.`
* `settrace(tracefunc: Callable, trace_instructions:Optional[bool]=False) -> 
None # added keyword.`
* `gettracestate() -> Dict[str, Any] # new.`
Behavior:
* `gettracestate()` returns the complete trace-related state: currently, 
`tracefunc` and `trace_instructions` fields.
* `gettrace()` raises an exception if any of the trace state does not match the 
old behavior, i.e. if `trace_instructions` is set.


3. New API, but with extensible keyword args:
* `settracestate(tracefunc: Callable, trace_instructions:Optional[bool]=False) 
-> None # new.`
* `gettracestate() -> Dict[str, Any] # new.`
Behavior:
* `settrace()` raises if `gettracestate()` is not None.
* `settracestate()` raises if `gettrace()` is not None.


As I see it:
* approach #1 is more conservative because it does not modify the old API.
* approach #2 is more extensible because all future features can be represented 
by the state dictionary.
* approach #3 has both of these strengths, but is also the most work.

Examples of possible future features via keywords:
* branch-level tracing, as briefly disscussed above.
* instruction filtering set, which could be a more general version of the 
branch tracing.

I intend to prototype one or both of these, but I'm also feeling a bit of time 
pressure to get the basic feature on track for 3.7.

--

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[STINNER Victor]

STINNER Victor added the comment:

See aslo issue #29502: "Should PyObject_Call() call the profiler on C 
functions, use C_TRACE() macro?"

--

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[George King]

George King added the comment:

I'm not sure exactly, but the way I see it (for code coverage), we want to 
trace transitions between basic blocks. So I would define it as: each entry 
into a BB is traced, with a tuple of (previous_offset, current_offset). This 
way when a function call starts, we callback with (-1, 0), and then get a 
callback for every transition between BBs. The code is well covered if we 
observe every possible transition.

I am not clear on the precise details, e.g. regarding unconditional branches. 
Since for code coverage this is essentially on optimization over 
per-instruction mode, I intend to first work out correctness details and test 
cases for the coverage tool, and then once the tests solid add the optimization.

I'm happy to discuss more, but this aspect is a lower priority for me (I still 
have to work out remaining correctness issues with my opcode analysis). Would 
it make sense to split it out into a second issue?

--

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[STINNER Victor]

STINNER Victor added the comment:

> I did it this way because I would like to consider adding a third mode, which 
> would only trigger tracing for interesting control-flow events, namely steps 
> for which the previous instruction was a branch.

Hum, let's use https://en.wikipedia.org/wiki/Basic_block terminology.

The callback would be called when you enter and exit a basic block? Or only on 
exit?

Only on conditional branches? Or also on unconditional branches?

In term of instructions, can give examples of instructions which would be 
traced or not?

IMHO the two instruction level modes would be useful.

--

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[George King]

George King added the comment:

Attached is a new patch, which does not settrace/gettrace and instead offers 
new settraceinst/gettraceinst per Victor's recommendation.

I did not implement the proposed behavior of raising an exception if the old 
APIs are used when the inst_tracing flag is set. However I do think it makes 
sense to do so.

The new sys.settraceinst function takes two arguments: a function and an 
integer flag that is currently interpreted as a boolean (whether or not to 
enable instruction level tracing).

I did it this way because I would like to consider adding a third mode, which 
would only trigger tracing for interesting control-flow events, namely steps 
for which the previous instruction was a branch. The motivation is that I 
expect per-instruction tracing to be very slow, and for the code coverage use 
case at least, these are the interesting events. For this to be useful, a 
(prev_offset, current_offset) pair would need to be passed as to the trace 
callback. I am not sure if this would be useful to other applications, e.g. pdb.

--
Added file: http://bugs.python.org/file46547/settraceinst.diff

___
Python tracker 

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

[issue29400] Add instruction level tracing via sys.settrace

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
stage:  -> test needed
title: Instruction level tracing via sys.settrace -> Add instruction level 
tracing via sys.settrace
versions: +Python 3.7 -Python 3.6

___
Python tracker 

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