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

[Yao Qi <qiyaoltc@gmail.com>]

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

> What I'm less clear about is what changes you are requesting in order to
> establish that interface.
>
> Should we just document it that way?

Yes, I think so.  (,Record)Instruction.{pc, data, decode, size} should
behave as expected, .pc should return the address of instruction, and
.data should return the bytes of instruction, .decode should return a
string of asm code.

From documentation point of view, these four attributes are documented
in Instruction, and RecordInstruction extends Instruction.

> Should we implement an Instruction base class that throws in all functions?
> Should we implement an Instruction base class that returns None in all
> functions?

This is the C implementation decision, not related to Python interface nor
document.  Python script can only get RecordInstruction objects via
Record.instruction_history, and RecordInstruction.{pc, data, decode,
size} should behave as we documented for Instruction.  So far, that is
no way in python script to get Instruction objects.  We can either throw
exceptions or return None. (I personally prefer exceptions, if you
really want me to choose one).

Suppose, one day, we add a new python interface like
gdb.Inferior.read_insn (start_pc,) returns Instruction objects.  The These
objects should behave as we already documented.  In C code, we can
change Instruction's getset functions to do something meaningful rather
than throwing exception.

-- 
Yao (齐尧)