Re: [PATCH v6 9/9] Add documentation for new record Python bindings.

[Yao Qi <qiyaoltc@gmail.com>]

"Wiederhake, Tim" <tim.wiederhake@intel.com> writes:

>> I read them again this morning, and have a design question in general, why
>> are they specific to btrace?
>> (...)
>> Can add a base class like RecordInstruction, which have some basic attributes
>> for all record methods, and BtraceInstruction extends it to add more btrace
>> specific attributes.
>
> Unfortunately, the interfaces to the "full" and "btrace" recording differ quite
> much. So even for "common" attributes, the code for the base class instruction
> and function segment objects would have to "if (method == ...)" through all
> recording methods, cluttering it, making it harder to maintain and
> potentially

Do you have a concrete example?  If you have to "if (method == ...)" in
python code (outside of gdb), there is something wrong on design in
python code.  I believe there are some design patterns for this kind of
issue "if (method == ...)".

> cause trouble if we introduce another recording format in the future when
> functions in the base class suddenly are not implemented for all methods
> anymore.
>
> My idea was to make use of Python's philosophy of duck-typing. Having specific
> (C wrapper) objects for each recording method solves the problem of how to
> obtain the requested data from the recording "back end". If we name respective
> functions and attributes the same in these classes, we "quack like a duck" and
> create the same common interface for the user from Python's perspective.
>

but you can't have a common interface because the python api is btrace
specific.  Suppose we have gdb.FullInstruction for "full", what
attributes do we have? .number and .pc maybe?  With the python api
design like this, how can I write a python code to trace data regardless
of which method is being used?  Ideal design in my mind is like this (I
hope concrete example like this helps discussion)

class RecordInstruction(object)

      # fields .pc and .number

class FullRecordInstruction(RecordInstruction)

class BtraceInstruction(RecordInstruction)

      # field .error

Client python code can get a list of RecordInstruction to process,
without being aware which method is used.

Use gdb.find_pc_line (pc) to get gdb.Symtab_and_line, so we don't need
to have BtraceInstruction.sal.

BtraceInstruction .data, .decoded, .size, and .is_speculative, shouldn't
be in BtraceInstruction.  They are about instruction.  We need to put
them into a separate class, like gdb.Instruction, and add some function
to get gdb.Instruction from pc.

I'll give comments to BtraceFunctionCall later.

-- 
Yao (齐尧)