I suspect that you're running into the issue where compiler optimizations
are *forced* on for ceval.c.
There's a comment near the top about this. Just comment out this line:
#define PY_LOCAL_AGGRESSIVE
We tried to define that macro conditionally, but something broke because
the C stack frame for _PyEval_EvalFrameDefault became enormous without
optimization, and some tests failed. (Maybe it was Victor's refleak test?
The git history will tell you more if you're really interested.)
This is a nasty trap (I fell in myself, so that makes it nasty :-), but the
proper fix would be convoluted -- we'd need a way to enable or disable this
separately so the specific test can run but developers trying to step
through ceval.c will be able to see the unoptimized code.
On Fri, May 21, 2021 at 12:40 PM Skip Montanaro <skip.montan...@gmail.com>
wrote:
> I'm having a hard time debugging some virtual machine code because GDB
> won't break where it's supposed to. Here's my breakpoint #2:
>
> 2 breakpoint keep y 0x00005555556914fd
> ceval_reg.h:_PyEval_EvalFrameDefault:TARGET_JUMP_IF_FALSE_REG
> breakpoint already hit 1 time
> p/x oparg
> p (oparg >> 16) & 0xff | (oparg >> 8) & 0xff
> p oparg & 0xff
> p *fastlocals@4
>
> but when it breaks, it's not at the beginning of the case (that is, where
> the TARGET_JUMP_IF_FALSE_REG label is defined), but inside the SETLOCAL
> macro of the COMPAR_OP_REG case! (That is, it's not anywhere close to the
> correct place.)
>
> case TARGET(COMPARE_OP_REG): {
> int dst = REGARG4(oparg);
> int src1 = REGARG3(oparg);
> int src2 = REGARG2(oparg);
> int cmpop = REGARG1(oparg);
> assert(cmpop <= Py_GE);
> PyObject *left = GETLOCAL(src1);
> PyObject *right = GETLOCAL(src2);
> PyObject *res = PyObject_RichCompare(left, right, cmpop);
> *SETLOCAL(dst, res);*
> if (res == NULL)
> goto error;
> DISPATCH();
> }
>
> It actually breaks in the Py_XDECREF which is part of the SETLOCAL macro:
>
> #define SETLOCAL(i, value) do { PyObject *tmp = GETLOCAL(i); \
> GETLOCAL(i) = value; \
> *Py_XDECREF(tmp)*; } while (0)
>
> (actually, in the Py_DECREF underneath the Py_XDECREF macro). I've
> configured like so:
>
> ./configure --with-pydebug --with-tracerefs --with-assertions
>
> Python/ceval.c is compiled with this GCC command:
>
> gcc -pthread -c -Wno-unused-result -Wsign-compare -g -Og -Wall -std=c99
> -Wextra -Wno-unused-result -Wno-unused-parameter
> -Wno-missing-field-initializers -Wstrict-prototypes
> -Werror=implicit-function-declaration -fvisibility=hidden
> -I./Include/internal -I. -I./Include -DPy_BUILD_CORE -o Python/ceval.o
> Python/ceval.c
>
> I don't know if this is a GCC problem, a GDB problem, or a Skip problem. Is
> there more I can do to help the tool chain break at the correct place? It
> seems that if I break at a hard line number, GDB does the right thing, but
> I'd kind of prefer to use the symbolic label instead. I rather like the
> notion of breaking at a label name, but if GCC/GDB can't figure things out,
> I guess I'll have to live with line numbers.
>
> Thanks,
>
> 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/EOTDLRRUR6J6KMM6ZKBDJDAZLBEY6BBP/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________
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/DVB2GVLD4BPICVP37C56K7UYD2M3P6EE/
Code of Conduct: http://python.org/psf/codeofconduct/
