From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122602 invoked by alias); 7 Mar 2017 11:53:51 -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 122589 invoked by uid 89); 7 Mar 2017 11:53:50 -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=morning X-HELO: mail-wr0-f194.google.com Received: from mail-wr0-f194.google.com (HELO mail-wr0-f194.google.com) (209.85.128.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 07 Mar 2017 11:53:49 +0000 Received: by mail-wr0-f194.google.com with SMTP id l37so25276988wrc.3 for ; Tue, 07 Mar 2017 03:53:49 -0800 (PST) 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=Xh7r7117fy+M/fdJSVbAioX69bcr8ft1KaZB0GxOt5U=; b=UL2wrQ927N/MLzj9cc2RpU2IJH+MpxCLuCLRzm8GqHkzQvalVPxIsSG1AxeAd/iDLf gTS8H1SeFBvSeZ2Xj+P3b9DUM2Fx/GvwkEsFadUzta6emKcqF9WTirWBR8/eSDSImsqz 93cmGxygFfZdFq4QBmske1kPaqI0R9aQd62b8NqFielghYUP73Fyrm3ciwgILzSDe1rS FQkSPv+pAkE+QpXwpsyJnq2y75yotHpoEJ/WTCi5VBHj80y7MufY1n+hBWUiIqBuLyqb TUqJGPOhcMVaQs60K/8fHgYvgzHB47zJgQmsX7K2Q48b3W+P3iSYfcPidY4pEKANK6ia QItA== X-Gm-Message-State: AMke39lXsx17xUS9cvNdD8pqoOlJh7jirXvdswR/oMJLGJ7bZ3aKRETENmQyAER9C+cjDQ== X-Received: by 10.223.162.205 with SMTP id t13mr20649390wra.155.1488887627943; Tue, 07 Mar 2017 03:53:47 -0800 (PST) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id v18sm30853509wrc.41.2017.03.07.03.53.45 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 07 Mar 2017 03:53:47 -0800 (PST) From: Yao Qi To: "Wiederhake\, Tim" Cc: "gdb-patches\@sourceware.org" , "Metzger\, Markus T" , "palves\@redhat.com" , "xdje42\@gmail.com" Subject: Re: [PATCH v6 9/9] Add documentation for new record Python bindings. 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> Date: Tue, 07 Mar 2017 11:53:00 -0000 In-Reply-To: <9676A094AF46E14E8265E7A3F4CCE9AF942666@irsmsx105.ger.corp.intel.com> (Tim Wiederhake's message of "Mon, 6 Mar 2017 08:56:42 +0000") Message-ID: <86wpc1uwtz.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/msg00060.txt.bz2 "Wiederhake, Tim" writes: >> I read them again this morning, and have a design question in general, w= hy >> are they specific to btrace? >> (...) >> Can add a base class like RecordInstruction, which have some basic attri= butes >> for all record methods, and BtraceInstruction extends it to add more btr= ace >> 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 instru= ction > and function segment objects would have to "if (method =3D=3D ...)" throu= gh all > recording methods, cluttering it, making it harder to maintain and > potentially Do you have a concrete example? If you have to "if (method =3D=3D ...)" 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 =3D=3D ...)". > 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 spe= cific > (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 respe= ctive > 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. --=20 Yao (=E9=BD=90=E5=B0=A7)