This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 (齐尧)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]