Re: GDB 8.0 release/branching 2017-03-20 update

Yao Qi
2017-03-31T13:55:45Z

"Metzger, Markus T" <markus.t.metzger@intel.com> writes:

> I thought we need it because we may get RecordFullInstruction in the future
> that needs to store different data and install different functions.
>
> They will behave identical but will have different implementations.

Do you have some concrete reasons that we may change
Record{Full,Btrace,...}Instruction in C? I can't figure out the reason
in the future we do the change, so I don't worry it now.

>
> Can they pretend to be the same type in Python?

Suppose one day in the future, we really need such change. We can still
have different C structs for different record methods, different
PyTypeObject but with the same .tp_name "gdb.RecordInstruction" and
different .tp_getset. I hacked GDB code, and find python doesn't
complain that I call PyType_Ready with different PyTypeObject, but they
have the same .tp_name. Everything works fine.

If the change I do above is hacky, then we have to create sub-types of
RecordInstruction for different record methods in C
(gdb.priv.RecordFullinstruction for example?), but Python interface is
still documented as returning type gdb.RecordInstruction.

r = gdb.current_recording()
insn = r.instruction_history
print insn[0].pc
print insn[0].sal

and the in C code for .instruction_history,

if (obj->method == RECORD_METHOD_BTRACE)
return recpy_bt_instruction_history (obj->ptid, closure);
else if (obj->method == RECORD_METHOD_FULL)
{
gdbpy_ref<> list (PyList_New (0));
fullpy_insn_object * const obj = PyObject_New (fullpy_insn_object,
&fullpy_insn_type);

if (obj == NULL)
return NULL;

obj->insn.insn.pc = 11;
obj->insn.insn.size = 22;
PyList_Append (list.get (), (PyObject *) obj);

return PyList_AsTuple (list.get ());
}

return PyErr_Format (PyExc_NotImplementedError, _("Not implemented."));

Python code still uses insn[0] as the base type RecordInstruction, and
Python code doesn't need to know the sub-types of RecordInstruction C
code creates. We deliberately don't document these sub-types in GDB if
we add them. IMO, not every python types we added in C are public types.

--
Yao (齐尧)