From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72720 invoked by alias); 3 Mar 2017 11:10:04 -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 72680 invoked by uid 89); 3 Mar 2017 11:10:03 -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=sal, timwiederhakeintelcom, tim.wiederhake@intel.com, morning X-HELO: mail-wm0-f66.google.com Received: from mail-wm0-f66.google.com (HELO mail-wm0-f66.google.com) (74.125.82.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 03 Mar 2017 11:10:01 +0000 Received: by mail-wm0-f66.google.com with SMTP id m70so2580626wma.1 for ; Fri, 03 Mar 2017 03:10:01 -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=ycnfWVHp3rvdxAzWFLdBVHJxlpEaii2DQ0mbfwaOr9w=; b=h9MBQLZIH/OFn3O+vvMc8d6fbUpuhuAdJoXaI8+4/Fubz/96Vm6A/RtsqQm7DLyJ8c ITrKa/MfkzMe1bB3mzi45Lz4TZoQGpbBkkWG9CSlYyW+Vs3IUSn5JN0rKMftDYE5VMmA ODHEES3mPGI5HRgic14tZGure6FQ7b+VGVzgACXcFLONcqG3DkIf9ceX5fsf6W5q4JY+ mJZg/Lt7FyZ8D7Wc8CsBNOv9x4BXjbA7YBmsj+MFoLCwyFmDeIKhLbScO2+noNbmu0T4 QmfQ7swqes4/zMRnoXhHxM/8wOZeuNqQ0lbf5kHUBqsMIodIFOp1DiyrpRdtfsYBqyI6 y4bg== X-Gm-Message-State: AMke39lInUaTD+oS7+ZjSfKExIV+F+PtshSLYRKM1Lnkyw/MPqjTG/p/zhn8BweaokScYg== X-Received: by 10.28.88.129 with SMTP id m123mr2279551wmb.28.1488539400056; Fri, 03 Mar 2017 03:10:00 -0800 (PST) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id m78sm2592419wma.31.2017.03.03.03.09.58 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 03 Mar 2017 03:09:59 -0800 (PST) From: Yao Qi To: Tim Wiederhake Cc: gdb-patches@sourceware.org, markus.t.metzger@intel.com, 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> Date: Fri, 03 Mar 2017 11:10:00 -0000 In-Reply-To: <1486989450-11313-10-git-send-email-tim.wiederhake@intel.com> (Tim Wiederhake's message of "Mon, 13 Feb 2017 13:37:30 +0100") Message-ID: <86tw7apqf6.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/msg00023.txt.bz2 Tim Wiederhake writes: Hi Tim, I read them again this morning, and have a design question in general, why are they specific to btrace? > +The attributes and methods of instruction objects depend on the current > +recording method. Currently, only btrace instructions are supported. > + > +A @code{gdb.BtraceInstruction} object has the following attributes: > + > +@defvar BtraceInstruction.number > +An integer identifying this instruction. @var{number} corresponds to > +the numbers seen in @code{record instruction-history} > +(@pxref{Process Record and Replay}). > +@end defvar > + Why is it btrace specific? Instructions in history of any record methods can have a number or id, isn't? > +@defvar BtraceInstruction.error > +An integer identifying the error code for gaps in the history. > +@code{None} for regular instructions. > +@end defvar > + > +@defvar BtraceInstruction.sal > +A @code{gdb.Symtab_and_line} object representing the associated symtab > +and line of this instruction. May be @code{None} if the instruction > +is a gap. > +@end defvar > + > +@defvar BtraceInstruction.pc > +An integer representing this instruction's address. May be @code{None} > +if the instruction is a gap or the debug symbols could not be read. > +@end defvar Again, is it btrace specific? Any instruction will have an address, regardless of debug symbol. Secondly, we have BtraceInstruction.pc, do we still need BtraceInstruction.sal? The sal can be got from other python api, although these api may not exist. 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. > + > +@defvar BtraceInstruction.data > +A buffer with the raw instruction data. May be @code{None} if the > +instruction is a gap. > +@end defvar > + > +@defvar BtraceInstruction.decoded > +A human readable string with the disassembled instruction. Contains the > +error message for gaps. > +@end defvar > + > +@defvar BtraceInstruction.size > +The size of the instruction in bytes. Will be @code{None} if the > +instruction is a gap. > +@end defvar > + > +@defvar BtraceInstruction.is_speculative > +A boolean indicating whether the instruction was executed > +speculatively. Will be @code{None} for gaps. > +@end defvar Why are these four attributes about Btrace or even record? To me, they are about instruction decode or disassembly. > + > +The attributes and methods of function call objects depend on the > +current recording format. Currently, only btrace function calls are > +supported. > + > +A @code{gdb.BtraceFunctionCall} object has the following attributes: > + > +@defvar BtraceFunctionCall.number > +An integer identifying this function call. @var{number} corresponds to > +the numbers seen in @code{record function-call-history} > +(@pxref{Process Record and Replay}). > +@end defvar > + > +@defvar BtraceFunctionCall.symbol > +A @code{gdb.Symbol} object representing the associated symbol. May be > +@code{None} if the function call is a gap or the debug symbols could > +not be read. > +@end defvar > + > +@defvar BtraceFunctionCall.level > +An integer representing the function call's stack level. May be > +@code{None} if the function call is a gap. > +@end defvar > + > +@defvar BtraceFunctionCall.instructions > +A list of @code{gdb.BtraceInstruction} objects associated with this func= tion > +call. > +@end defvar > + > +@defvar BtraceFunctionCall.up > +A @code{gdb.BtraceFunctionCall} object representing the caller's > +function segment. If the call has not been recorded, this will be the > +function segment to which control returns. If neither the call nor the > +return have been recorded, this will be @code{None}. > +@end defvar > + > +@defvar BtraceFunctionCall.prev_sibling > +A @code{gdb.BtraceFunctionCall} object representing the previous > +segment of this function call. May be @code{None}. > +@end defvar > + > +@defvar BtraceFunctionCall.next_sibling > +A @code{gdb.BtraceFunctionCall} object representing the next segment of > +this function call. May be @code{None}. > +@end defvar > + Sorry, I don't understand BtraceFunctionCall, can you give an example? BtraceFunctionCall.symbol and .level indicates it represents a function call rather than a function. In the following example, f2 () { f1 (); } f3 () { f1 (); } main () { f2 (); f3 (); } Here are my understandings, - There are two BtraceFunctionCall objects bf1 and bf2 for f1, the first one, bf1, is about the call in f2 and the second one, bf2, is about the call in f3. - bf2.up is about the call in f2, and bf3.up is about the call in f3. - bf2.next_sibling =3D=3D bf3 and bf3.prev_sibling =3D=3D b2 Are they correct? --=20 Yao (=E9=BD=90=E5=B0=A7)