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

[Yao Qi <qiyaoltc@gmail.com>]

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

> It is certainly not a must.  It might make things easier (or just more
> convenient)
> but if we want a minimal Instruction base class, we would only need pc, decode
> (rename to disassembly?), and size.
>
> Record instructions will add data and sal and at least record-btrace will add
> is_speculative.  In order to not complicate things too much I would add
> is_speculative also to record-full (even if it is always false) and
> put everything
> into a single RecordInstruction class for all record targets.  OK?
>

I hate the over-complicated design as well.  That is fine by me.

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

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

-- 
Yao (齐尧)