From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96228 invoked by alias); 7 Apr 2017 08:10:53 -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 96108 invoked by uid 89); 7 Apr 2017 08:10:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f182.google.com Received: from mail-wr0-f182.google.com (HELO mail-wr0-f182.google.com) (209.85.128.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Apr 2017 08:10:50 +0000 Received: by mail-wr0-f182.google.com with SMTP id o21so67620602wrb.2 for ; Fri, 07 Apr 2017 01:10:51 -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=b16CnwVV3a8F1wg/xIce55Djrir+n4RpkmEJCaAdiV0=; b=VgSV0csFct+68+n3Kl/ekxu/tm9a898UtIVQYuoeNDJ5S5/b3ODQiHbGO3jV5/9dGJ DOYjIYBrK+LQPsmCl8NALcj56F6NQJmOtcbnWApcV3oxCoxrLi/FG+t5sEVOEm+WWDBj f90C0ozPbk2nV4kh6K0fJNf8aURxR2d/OtR389SGUn3BMWa1OlEOSoojIebh/rffiKNL HWbJbGd3yFUAttlr/7KJc1VbbJht29JecgCwVGfx9TOsWWUKzh54ZN3zCXJx0Mx+r3hW rD0sBW1QxHGBtmNk7cylB8tE0XvT08kKsNKIP6Jbx62M3NQ2bKyFYuKsLrnGXCrIKMim Qnng== X-Gm-Message-State: AFeK/H0r6gX8S2jMIn1R2huRDFipCEBwvofzhyy1j0EVHEn4i1hwwOdzbNHKiYfPWmiyKQ== X-Received: by 10.28.6.213 with SMTP id 204mr22332261wmg.68.1491552650026; Fri, 07 Apr 2017 01:10:50 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id t16sm5057848wra.44.2017.04.07.01.10.48 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 07 Apr 2017 01:10:49 -0700 (PDT) From: Yao Qi To: "Wiederhake\, Tim" Cc: Joel Brobecker , "Metzger\, Markus T" , "gdb-patches\@sourceware.org" , "xdje42\@gmail.com" Subject: Re: GDB 8.0 release/branching 2017-03-20 update References: <86a885o0z2.fsf@gmail.com> <861stgo072.fsf@gmail.com> <86lgrn3uos.fsf@gmail.com> <86h92a4w86.fsf@gmail.com> <86h929wnxi.fsf@gmail.com> <20170331160246.xjlqgrrkayprdmba@adacore.com> <9676A094AF46E14E8265E7A3F4CCE9AF3C134157@IRSMSX106.ger.corp.intel.com> Date: Fri, 07 Apr 2017 08:10:00 -0000 In-Reply-To: <9676A094AF46E14E8265E7A3F4CCE9AF3C134157@IRSMSX106.ger.corp.intel.com> (Tim Wiederhake's message of "Thu, 6 Apr 2017 14:40:44 +0000") Message-ID: <86fuhkk58b.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-04/txt/msg00157.txt.bz2 "Wiederhake, Tim" writes: Hi Tim, I was off yesterday. Thanks for the summary. > The Python interface shall look like this (from Python's perspective): > > gdb: > Record start_recording([str method], [str format]) > Record current_recording() > None stop_recording() > > Unchanged. > > gdb.Record: > str method > str format > RecordInstruction begin > RecordInstruction end > RecordInstruction replay_position > RecordInstruction[] instruction_history > RecordFunctionSegment[] function_call_history > None goto(RecordInstruction insn) > > gdb.Record loses the "ptid" attribute. "instruction_history" and=20 > "function_call_history" actually returns a "list" or "list-like object" > as there is no way to enforce the type of elements in this list on a > language level in Python. Practically, these list will always contain > "RecordInstruction" / "RecordFunctionSegment" objects since we control > their creation. "*_history" may return "None" if the current recording > method cannot provide such a list. > > gdb.Instruction: > int pc > buffer data > str decode > int size >=20=09 > gdb.Instruction is meant to be an abstract base class. The user will > never receive a raw gdb.Instruction object and accessing any attribute > in this class will throw a "NotImplementedError" (from what I > understand, that's the preferred way to handle this kind of situation > in Python). =46rom the implementation point of view, it can be an abstract base class, but we don't have to mention it in Python/Document. Likewise, we don't apply the restriction that "user will never receive a raw gdb.Instruction object" on the Python interface. > > gdb.RecordInstruction (gdb.Instruction): > int pc > buffer data > str decode > int size > int error > gdb.Symtab_and_line sal > bool is_speculative >=20=09 > gdb.RecordInstruction is a sub class of gdb.Instruction. It loses > the "number" attribute. "error" will be "None" if there is no error. > > gdb.Instruction (gdb.Instruction): > int pc > buffer data > str decode > int size > ... >=20=09 > Created by other Python interfaces, e.g. a function that dissasembles > target memory. Right, to be clear, we focus on record/btrace instruction. > > gdb.RecordFunctionSegment: > gdb.Symbol symbol > int level > gdb.RecordInstruction[] instructions > gdb.RecordFunctionSegment up > gdb.RecordFunctionSegment prev > gdb.RecordFunctionSegment next >=20=09 > Renamed from "gdb.BtraceFunctionCall" to better fit the general scheme. "Segment" is less clear than "Call". Does this object represent something other than a function call? > Loses the "number" attribute. As above, "instructions" actually returns > a list / list-like object. "prev_sibling" and "next_sibling" are > renamed to "prev" and "next" for simplicity (discussed with Markus > off-list). It is a good renaming to me. >=20=09 > Correct so far? > Yes, I think so :) > Initially I supported the idea of losing the "number" attributes in > "gdb.RecordInstruction" and "gdb.RecordFunctionSegment", but I see a > problem with that now: If an instruction is executed multiple times (e.g= . in a > loop), all user visible attributes for these gdb.RecordInstruction object= s are > the same, nevertheless a comparison with "=3D=3D" does not yield "True" b= ecause they > represent, well, two different instances of execution of that instruction. > Keeping the "number" attribute in would show the user, why those objects = are not > equal. Therefore I propose to retain the "number" attribute in > "gdb.RecordInstruction" and for symmetry in "gdb.RecordFunctionSegment" a= s well. > As far as I can see, it is not a problem to me. The multiple instances of the same instruction are different, because the same instruction executed multiple times. IOW, gdb.RecordInstruction from different slots of .instruction_history are different. > Markus and I further discussed how we handle gaps or other errors in the = trace > from the Python point of view. We came to the conclusion that it would be > beneficial for the user if we replaced the definition of "gdb.RecordInstr= uction" > above with the following two: > > gdb.RecordInstruction (gdb.Instruction): > int pc > buffer data > str decode > int size > int number > gdb.Symtab_and_line sal > bool is_speculative >=20=09 > gdb.RecordGap: > int number > str error_message > int error_code > > Does NOT inherit from gdb.Instruction. > > gdb.Record.instruction_history would then not "return a list of > RecordInstructions" but instead "return a list of RecordInstructions and > (potentially) RecordGaps". Yeah, I can see the motivation of this change, because it is strange to have a field "error" in gdb.RecordInstruction to indicate this. > > The user needs to distinguish between instructions and gaps somehow anywa= y, and > this solution would let them do so quite nicely. Example code: > > r =3D gdb.current_recording() > for insn in r.instruction_history: > try: > print insn.pc, insn.sal > except: > # It's a gap! > print insn.error_message > I don't like using exception for control flow. If I understand "gap" correctly, it is caused something interrupt the tracing. I'd like to change the interface like this, gdb.InstructionHistory a list of gdb.RecordInstruction gdb.RecordGap (or gdb.RecordStopReason) It saves a list of instructions and why the record is stopped or interrupted. It can be different reasons, like hardware limitation, or user preference (user only wants to record/trace instructions executed in current function foo, so any function calls in foo will cause a gap in the history. In this way, gdb.RecordGap don't have to be an error). gdb.Record.instruction_history returns a list of gdb.InstructionHistory. --=20 Yao (=E9=BD=90=E5=B0=A7)