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

["Metzger, Markus T" <markus.t.metzger@intel.com>]

Hello Yao,

> > 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.

OK.  That shouldn't take long.  Also the other items we discussed shouldn't
take long to implement.  We agreed to remove ptid and number from
RecordBtraceInstruction and rename it to RecordInstruction.

When we do this for record-full, we need different functions and we may also
want to store different data in the python object.

Anticipating such a change, I would document class RecordInstruction as we
discussed but keep RecordBtraceInstruction.  We may introduce yet another
abstract base class RecordInstruction.  OK?

We may not need to document class RecordBtraceInstruction since it does not
really add anything to class RecordInstruction.  The interface consists of classes
Instruction and RecordInstruction.  OK?


> > 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.

We will need to introduce another derived class DisassembleInstruction
since it will want to store data in the python object and we don't want that
data in RecordInstruction objects, so we can't add it to the Instruction base
class.

That's again talking about the implementation.  If we can model this in
Python without introducing new classes, I'm fine, as well.  We should also
do it like this for classes RecordInstruction and RecordBtraceInstruction in
that case.

Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928