> Just turn off optimisation when you want to single-step.

But I don't just want to single-step. I want to break at the target
label associated with a specific opcode. (I am - in fits and starts -
working on register-based virtual machine instructions). If I'm
working on, for example, the register version of POP_JUMP_IF_FALSE,
stepping through a bunch of instances of the working register version
of LOAD_FAST or EXTENDED_ARG isn't going to be helpful. Further, I
have a set of GDB commands I want to execute at each breakpoint. And I
want to do this across GDB sessions (so, I save breakpoints and
user-defined commands in a GDB command file).

Just to make things concrete, here's what I want to print every time I
hit my JUMP_IF_FALSE_REG statement's code:

define print_opargs_jump
  p/x oparg
  p (oparg >> 16) & 0xff | (oparg >> 8) & 0xff
  p oparg & 0xff
  p *fastlocals@4
end

This break command should do the trick:

break ceval_reg.h:_PyEval_EvalFrameDefault:TARGET_JUMP_IF_FALSE_REG
  commands
    print_opargs_jump
  end

but it doesn't. GDB stops execution in some completely other one of
the 50+ instructions I've implemented so far. And not even at the
start of said other instruction. This problem is true whether I
compile with -g -Og or -g -O0. The only difference between the two is
that GDB stops execution at different incorrect locations. That, as
you might imagine, makes debugging difficult.

Setting breakpoints by line number works as expected. In all the years
I've been using GDB I've never had a problem with that. However,
that's fragile in the face of changing offsets for different
instructions in the C code (add a new instruction, add or delete C
code, reorder instructions for some reason, etc), it's difficult to
maintain those kinds of breakpoints. I wrote a crude little script
that converts the above break command into this:

break ceval_reg.h:440
  commands
    print_opargs_jump
  end

This is just a workaround until someone (unlikely to be me) solves the
problem with breaking at labels.

If someone could refute or verify my contention that breaking via
labels is broken, I'd much appreciate it. I've not yet checked setting
labeled breakpoints directly in ceval.c. To minimize merge conflicts,
I'm implementing my register instructions in a new header file,
Python/ceval_reg.h, which is #included in ceval.c at the desired spot.
Maybe that factors into the issue.

Skip
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DE33TZBPIRV5DEOFFZBFDXPWRLZE47IB/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to