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

[Yao Qi <qiyaoltc@gmail.com>]

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

> RecordInstruction wants to store ptid and insn# and compute pc, data, and
> disassembled string from those.  It may need to read memory from binaries
> that have already been unmapped.  But we only want to read memory if we
> really have to, so we can't just store the memory in the Instruction object.
>

They are all about internal representation, aren't they?  Let me be
clear, "internal representation" is about the C code, not python one.

> DisassembleInstruction can't use ptid and insn# since insn# doesn't mean
> anything outside of record targets.  It will need to store different information
> from which it can compute pc, data, and the disassembled string.
>
> While they provide the same interface (i.e. member functions) to the user, they

"the same interface" is python interface or c interface?  I assume you
meant python interface.

> store different information internally and they use different
> algorithms.  In C++
> I would model this with an abstract base class.  How would one model
> this in Python?
>

We can have the same interfaces in Python but with different
implementations in CPython.  Suppose we have a base class Instruction in
python, and it has attributes, pc, size, data and decoded.  Its CPython
implementation is what current BtraceInstruction does, which only gets
contents when they are accessed.  However, we are free to change the
implementation to store all needed contents when the object is created.
Classes Instruction, BtraceInstruction, and FullInstruction can have
their own functions to access these four attributes in different ways.
The key point is that record.instruction_history (in Python) return a
list of objects which has these four attributes in common.  It doesn't
matter in Python on how to get their value/contents.

>
>> > What won't work is that we simply extend an Instruction base class by
>> > adding new functions and data members.  We need to overwrite every
>> > function in the base class and each derived class will provide its own set
>> > of data members to work on.
>> 
>> I don't expect the change like that.
>
> I didn't understand your comment.  Would you please rephrase it?

What I meant is that I don't expect adding *new* functions or data members
in the base class, but I don't see why can't override function in the
base class.

-- 
Yao (齐尧)