[Python-Dev] GDB not breaking at the right place

2021年5月21日 12:40:47 -0700

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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/[email protected]/message/EOTDLRRUR6J6KMM6ZKBDJDAZLBEY6BBP/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to