Marcel Plch <[email protected]> added the comment:
The problem is with this function:
static PyObject *
builtin_id(PyModuleDef *self, PyObject *v)
/*[clinic end generated code: output=0aa640785f697f65 input=5a534136419631f4]*/
{
return PyLong_FromVoidPtr(v);
}
It's a one-liner, so the compiler really likes to inline it.
Without the inline optimization, the additional "next" command makes a jump
into the function.
But when the function is inlined and you set a breakpoint to it, the line is
just seen as a function from the debugger, that means you already are inside
and the "next" makes the debugger exit this line, and so the function.
More graphical explanation:
non-inline case:
br
{
next
return PyLong_FromVoidPtr(v);
inline case:
br
return PyLong_FromVoidPtr(v);
next
"Some code without access to the func arguments' debug symbols"
I propose two possible solutions:
1) Skip whole test_gdb when optimizations are used (who debugs with them
anyway?)
2) Conditionalize the "next". (this could be hard as we would need to know when
the function is inlined)
Also, I have found out that when configured with --with-pydebug and
--enable-optimizations, tests stop to fail. (the failing bots are configuring
with --enable-optimizations only)
----------
_______________________________________
Python tracker <[email protected]>
<https://bugs.python.org/issue32962>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
