[Python-Dev] seeing off SET_LINENO

[Michael Hudson]

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