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

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

Hello Yao,

> > I meant that's all we store internally.  Everything else, the pc, the
> > instruction's bytes,
> > the disassembly, even the is_speculative flag, is computed when the respective
> > function is called (or field is accessed).
> >
> 
> We can also compute them lazily in gdb.disassemble ().
> 
> > I think we already agreed to remove the ptid from the API.  I'm also
> > not really sure
> > we need the number in Python.  It is needed by the CLI to refer to an
> > instruction
> > but in Python we can use an instruction object directly.
> >
> > Once we drop those, the internal representation will be completely
> > different from the
> > external one.  And it will be record-(btrace-)specific.  I like that a
> > lot since computing
> 
> AFAICS, The internal representation of instruction object provided by
> gdb.disassemble () can be a base class, and record-(target-) specific
> instruction object can extend it, but doesn't have to.  It is an
> implementation decision, and user invisible, right?

Instruction would have to be an abstract class.  Then we could have two
derived classes DisassembleInstruction for the disassemble command
that likely wants to store the pc and maybe the inferior id - or even the
disassembled string.
And we have Record(Btrace)Instruction that wants to store the ptid
and the number in the recorded instruction-history.

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.

Thanks,
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