This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

> 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

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

-- 
Yao (齐尧)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]