summaryrefslogtreecommitdiffstats
path: root/Python/ceval.c
diff options
context:
space:
mode:
authorMichael W. Hudson <mwh@python.net>2002-09-11 15:36:32 (GMT)
committerMichael W. Hudson <mwh@python.net>2002-09-11 15:36:32 (GMT)
commit02ff6a99522bf0c734831841661ebd385ae8c417 (patch)
treefdb0a6ffa6b397e39fe09f03bee05fa8a650eb0b /Python/ceval.c
parent519a342d799a0222ca5290d152ee97d7818a9493 (diff)
downloadcpython-02ff6a99522bf0c734831841661ebd385ae8c417.zip
cpython-02ff6a99522bf0c734831841661ebd385ae8c417.tar.gz
cpython-02ff6a99522bf0c734831841661ebd385ae8c417.tar.bz2
A slight change to SET_LINENO-less tracing.
This makes things a touch more like 2.2. Read the comments in Python/ceval.c for more details.
Diffstat (limited to 'Python/ceval.c')
-rw-r--r--Python/ceval.c23
1 files changed, 18 insertions, 5 deletions
diff --git a/Python/ceval.c b/Python/ceval.c
index 6364c3f..362cd0b 100644
--- a/Python/ceval.c
+++ b/Python/ceval.c
@@ -2909,7 +2909,7 @@ maybe_call_line_trace(int opcode, Py_tracefunc func, PyObject *obj,
>> 21 LOAD_CONST 0 (None)
24 RETURN_VALUE
- If a is false, execution will jump to instruction at offset
+ If 'a' is false, execution will jump to instruction at offset
15 and the co_lnotab will claim that execution has moved to
line 3. This is at best misleading. In this case we could
associate the POP_TOP with line 4, but that doesn't make
@@ -2920,21 +2920,32 @@ maybe_call_line_trace(int opcode, Py_tracefunc func, PyObject *obj,
current instruction offset matches the offset given for the
start of a line by the co_lnotab.
- This also takes care of the situation where a is true.
+ This also takes care of the situation where 'a' is true.
Execution will jump from instruction offset 12 to offset 21.
Then the co_lnotab would imply that execution has moved to line
5, which is again misleading.
+
+ Why do we set f_lineno when tracing? Well, consider the code
+ above when 'a' is true. If stepping through this with 'n' in
+ pdb, you would stop at line 1 with a "call" type event, then
+ line events on lines 2 and 3, then a "return" type event -- but
+ you would be shown line 5 during this event. This is a change
+ from the behaviour in 2.2 and before, and I've found it
+ confusing in practice. By setting and using f_lineno when
+ tracing, one can report a line number different from that
+ suggested by f_lasti on this one occasion where it's desirable.
*/
if ((frame->f_lasti < *instr_lb || frame->f_lasti >= *instr_ub)) {
PyCodeObject* co = frame->f_code;
- int size, addr;
+ int size, addr, line;
unsigned char* p;
size = PyString_GET_SIZE(co->co_lnotab) / 2;
p = (unsigned char*)PyString_AS_STRING(co->co_lnotab);
addr = 0;
+ line = co->co_firstlineno;
/* possible optimization: if f->f_lasti == instr_ub
(likely to be a common case) then we already know
@@ -2951,12 +2962,14 @@ maybe_call_line_trace(int opcode, Py_tracefunc func, PyObject *obj,
if (addr + *p > frame->f_lasti)
break;
addr += *p++;
- p++;
+ line += *p++;
--size;
}
- if (addr == frame->f_lasti)
+ if (addr == frame->f_lasti) {
+ frame->f_lineno = line;
call_trace(func, obj, frame,
PyTrace_LINE, Py_None);
+ }
*instr_lb = addr;
if (size > 0) {
while (--size >= 0) {