I've submitted a(nother) patch to sf that removes SET_LINENO:
http://www.python.org/sf/587993
It supports tracing by digging around in the c_lnotab[*] to see when
execution moves onto a different line.
I think it's more or less sound but any changes to the interpreter
main loop are going to be subtle, so I have a few points to raise
here. In no particular order:
1) this is a change I'd like to see anyway:
the use of f->f_lasti in the main loop is confusing. let's just set
it at the start of opcode dispatch and leave it the hell alone.
there's actually what is probably a very old bug in the
implementation of SET_LINENO. It does more or less this:
f->f_lasti = INSTR_OFFSET();
/* call the trace function */
It should do this:
f->f_lasti = INSTR_OFFSET() - 3;
/* call the trace function */
The field is called f_LASTi, after all...
2) As I say in the patch, I will buy anyone a beer who can explain
(without using LLTRACE or reading a lot of dis.py output) why we
don't call the trace function on POP_TOP opcodes.
3) The patch changes behaviour -- for the better! You're now rather
less likely to get the trace function called several times per
line.
4) The patch installs a descriptor for f_lineno so that there is no
incompatibility for Python code. The question is what to do with
the f_lineno field in the C struct? Remove it? That would
(probably) mean bumping PY_API_VERSION. Leave it in? Then its
contents would usually be meaningless (keeping it up to date would
rather defeat the point of this patch).
5) We've already bumped the MAGIC for 2.3a0, so we probably don't need
to do that again.
6) Someone should teach dis.py how to find line breaks from the
c_lnotab. I can do this, but not right now....
7) The changes tickle what may be a very old bug in freeze:
http://www.python.org/sf/588452
8) I haven't measured the performance impact of the changes to code
that is tracing or code that isn't. There's a possible
optimization mentioned in the patch for traced code. For not
traced code it MAY be worthwhile putting the tracing support code
in a static function somewhere so there's less code to jump over in
the main loop (for i-caches and such).
9) This patch stops LLTRACE telling you when execution moves onto a
different line. This could be restored, but
a) I expect I'm the only persion to have used LLTRACE recently
(debugging this patch).
b) This will cause obfuscation, so I'd prefer to do it last.
Comments welcome!
Cheers,
M.
[*] I've cheated with my sigmonster:
--
34. The string is a stark data structure and everywhere it is
passed there is much duplication of process. It is a perfect
vehicle for hiding information.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4