From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83987 invoked by alias); 27 Mar 2017 16:03:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 83977 invoked by uid 89); 27 Mar 2017 16:03:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mail-lf0-f52.google.com Received: from mail-lf0-f52.google.com (HELO mail-lf0-f52.google.com) (209.85.215.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Mar 2017 16:03:07 +0000 Received: by mail-lf0-f52.google.com with SMTP id j90so24916587lfk.2 for ; Mon, 27 Mar 2017 09:03:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=n5oPfrLS6p9RyOd/OSgworz7LCGwDyu4C388CWPOv8Y=; b=EN0goh9dnsz/2PekG9E6fcLL9HI6LSs2KYdr1t3DU0+5qO87inWi6wwxJMpsbV0OTl nSchqr0FCX112SDctza0O7K3L5eVzNo7LxnyYp7h0PnRzMzzUC9bg9mbHCFquE0LBjN7 67iVm3FSR8XiitYaRakmMSjS7mcKE6aWt5esAiMq4LLJgjzfNIzaPwcnxd4NyqJ7XKN1 dtdrAPXkEURq8SIsNbDRyZZ5BjVKQL6XutMmG06/uNHyumrLQIgyni9YN66SWxIef61g SC2D0N1+t8s0ezAybS+E66kjObj8f1CtlapP65a1QRtAnzuyfJpjYHaeCcdSWn/KqWFZ oClg== X-Gm-Message-State: AFeK/H33+vHt1Yhdw802OQ9TDTg3BS5tjleveKegTi6XCETw52F+0x3ZfEoZY1+Np7qGEw== X-Received: by 10.28.218.71 with SMTP id r68mr10693531wmg.59.1490630585643; Mon, 27 Mar 2017 09:03:05 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id g5sm1229216wrb.48.2017.03.27.09.03.04 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 27 Mar 2017 09:03:04 -0700 (PDT) From: Yao Qi To: "Metzger\, Markus T" Cc: "gdb-patches\@sourceware.org" , "Wiederhake\, Tim" , "xdje42\@gmail.com" , Joel Brobecker Subject: Re: GDB 8.0 release/branching 2017-03-20 update References: <20170320201629.pbjzaqsnvs7dx7f2@adacore.com> <86zigevkv0.fsf@gmail.com> <86inn1utkp.fsf@gmail.com> <86inmzvrbx.fsf@gmail.com> <86shm2u47t.fsf@gmail.com> <86wpbbnf1f.fsf@gmail.com> Date: Mon, 27 Mar 2017 16:03:00 -0000 In-Reply-To: (Markus T. Metzger's message of "Mon, 27 Mar 2017 12:46:38 +0000") Message-ID: <86shlyoggb.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00469.txt.bz2 "Metzger, Markus T" writes: > 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 obje= ct. > They are all about internal representation, aren't they? Let me be clear, "internal representation" is about the C code, not python one. > DisassembleInstruction can't use ptid and insn# since insn# doesn't mean > anything outside of record targets. It will need to store different info= rmation > 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 "the same interface" is python interface or c interface? I assume you meant python interface. > 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? > We can have the same interfaces in Python but with different implementations in CPython. Suppose we have a base class Instruction in python, and it has attributes, pc, size, data and decoded. Its CPython implementation is what current BtraceInstruction does, which only gets contents when they are accessed. However, we are free to change the implementation to store all needed contents when the object is created. Classes Instruction, BtraceInstruction, and FullInstruction can have their own functions to access these four attributes in different ways. The key point is that record.instruction_history (in Python) return a list of objects which has these four attributes in common. It doesn't matter in Python on how to get their value/contents. > >> > 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. >>=20 >> I don't expect the change like that. > > I didn't understand your comment. Would you please rephrase it? What I meant is that I don't expect adding *new* functions or data members in the base class, but I don't see why can't override function in the base class. --=20 Yao (=E9=BD=90=E5=B0=A7)