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

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

Hello Yao,

> >> > I'm wondering how much of this discussion is really a question of
> >> > sub-classing
> >> > and how much of it is about documentation.  Would I even be able to tell the
> >> > difference in my python scripts that use the API?
> >>
> >> All the user visible stuff should be covered in this discussion.  We
> >> need to mention that "gdb.RecordInstruction extends gdb.Instruction" in
> >> the document, so that we don't have to document gdb.Instruction
> >> attributes again in gdb.RecordInstruction.
> >>
> >> >
> >> > The duck typing argument makes sense to me and I'm not familiar enough
> >> > with implementing Python to have an opinion on how this should be done.
> >> > Do we have an expert on this in the GDB community?
> >> >
> >>
> >> The duck typing is about writing python code, but I raise my concerns in
> >> this thread from the view of controlling the API *interface* for
> >> different record methods by means of inheritance.  With or without
> >> inheritance, the python script still can do duck typing, no problem, but
> >> we will end up having completely different ways of organizing these
> >> interface.  Suppose we have three record methods, "btrace", "full" and
> >> "bar", in current approach, we need to document all the attributes for
> >> these three methods, although some of them are in common.  Why don't we
> >> put these common attributes into a base class, and only document the
> >> base class *once*?
> >
> > Makes sense.  Is this how it is usually implemented in Python?
> >
> 
> I don't know.
> 
> > I liked about the design that we could have a record-(target-)specific internal
> > representation.  IIRC we only store the thread's ptid and the instruction
> number
> > in that thread's instruction history.  An Instruction object provided by some
> > future gdb.disassemble() function will need a different internal representation.
> > Will we be able to do this with a class hierarchy?
> >
> 
> What do you mean by "internal representation"?  They are not internal,
> all of them are externally visible.

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

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
the disassembly is rather expensive and the string is relatively big.  When a script is
iterating over a few million instructions and all it needs is the pc or the sal or the
is_speculative flag to find a TSX region, we don't want to disassemble the instruction.


> >> Further, with such base class, we can guarantee that the client python
> >> scripts only access base class attributes are right even with the new
> >> record method may be added in the future.  In current approach, we write
> >> such python code "print(hex(i.pc), i.sal, i.decoded)" just because
> >> BtraceInstruction and FullInstruction *happen* to have these
> >> attributes.  What if a new record method "bar" have instruction trace
> >> which doesn't have attribute "decoded"?
> >
> > They'd get a not-implemented exception.
> >
> > I don't see how we could prevent that, though.  If we added another
> > recording method that didn't provide one of the functions the old
> > recording method's instruction object provided, it will have to fail
> > somehow.
> >
> > And we don't want scripts to restrict themselves to the Instruction
> > base class.  If they are using record-btrace we do want them to get
> > the sal from the instruction object, for example.
> 
> We don't restrict them to the base class.  They are still free using
> the class of their preferred record methods.  Again, my
> suggestion/design doesn't apply any restrictions to using these python
> APIs.  Instead, I intended to apply the restrictions to the python APIs.

It makes perfect sense to agree on the fields the various record targets
provide.

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