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

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

Hello Yao,

> > 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?
> 
> Why do we still keep RecordBtraceInstruction in Python?
> 
> > 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?
> 
> These two paragraphs are self-contradictory.  We don't need to keep
> RecordBtraceInstruction in Python, just use RecordInstruction.  We've
> already agreed that "put everything into a single RecordInstruction
> class for all record targets", as you said
> https://sourceware.org/ml/gdb-patches/2017-03/msg00420.html

This may be an interface/implementation confusion again.

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.

Can they pretend to be the same type in Python?


> >> > 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
> 
> What is "this"?
> 
> > Python without introducing new classes, I'm fine, as well.  We should
> > also
> 
> "without introducing new classes" in C?  What are the "new classes",
> Disassembleinstruction?
> 
> > do it like this for classes RecordInstruction and RecordBtraceInstruction in
> > that case.

This is the same as the above. 

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