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)