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


Hello Yao,

> > Instruction would have to be an abstract class.  Then we could have two
> > derived classes DisassembleInstruction for the disassemble command
> > that likely wants to store the pc and maybe the inferior id - or even the
> > disassembled string.
> > And we have Record(Btrace)Instruction that wants to store the ptid
> > and the number in the recorded instruction-history.
> 
> Instruction doesn't have to be an abstract class, instead, it can be a
> base class which has attribute pc, data, and disassembled string.  All
> of them can be used in Record(Btrace)Instruction too, but "data" and
> "disassembled string" can be got lazily.  Record(Btrace)Instruction
> extends Instruction, and add its own stuff.  In the future, we can add
> new RecordFooInstruction, extends Instruction, and add its own stuff too.

RecordInstruction wants to store ptid and insn# and compute pc, data, and
disassembled string from those.  It may need to read memory from binaries
that have already been unmapped.  But we only want to read memory if we
really have to, so we can't just store the memory in the Instruction object.

DisassembleInstruction can't use ptid and insn# since insn# doesn't mean
anything outside of record targets.  It will need to store different information
from which it can compute pc, data, and the disassembled string.

While they provide the same interface (i.e. member functions) to the user, they
store different information internally and they use different algorithms.  In C++
I would model this with an abstract base class.  How would one model this in Python?


> > What won't work is that we simply extend an Instruction base class by
> > adding new functions and data members.  We need to overwrite every
> > function in the base class and each derived class will provide its own set
> > of data members to work on.
> 
> I don't expect the change like that.

I didn't understand your comment.  Would you please rephrase it?

Thanks,
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

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