This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: GDB 8.0 release/branching 2017-03-20 update
"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 (齐尧)