This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v6 9/9] Add documentation for new record Python bindings.
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: "Wiederhake\, Tim" <tim dot wiederhake at intel dot com>
- Cc: "gdb-patches\@sourceware.org" <gdb-patches at sourceware dot org>, "Metzger\, Markus T" <markus dot t dot metzger at intel dot com>, "palves\@redhat.com" <palves at redhat dot com>, "xdje42\@gmail.com" <xdje42 at gmail dot com>
- Date: Tue, 07 Mar 2017 11:53:44 +0000
- Subject: Re: [PATCH v6 9/9] Add documentation for new record Python bindings.
- Authentication-results: sourceware.org; auth=none
- References: <1486989450-11313-1-git-send-email-tim.wiederhake@intel.com> <1486989450-11313-10-git-send-email-tim.wiederhake@intel.com> <86tw7apqf6.fsf@gmail.com> <9676A094AF46E14E8265E7A3F4CCE9AF942666@irsmsx105.ger.corp.intel.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 (齐尧)