From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99153 invoked by alias); 6 Apr 2017 14:40: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 98600 invoked by uid 89); 6 Apr 2017 14:40:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=nevertheless X-HELO: mga02.intel.com Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Apr 2017 14:40:48 +0000 Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Apr 2017 07:40:46 -0700 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga005.fm.intel.com with ESMTP; 06 Apr 2017 07:40:45 -0700 Received: from irsmsx106.ger.corp.intel.com ([169.254.8.202]) by IRSMSX103.ger.corp.intel.com ([169.254.3.241]) with mapi id 14.03.0319.002; Thu, 6 Apr 2017 15:40:44 +0100 From: "Wiederhake, Tim" To: Joel Brobecker , "Metzger, Markus T" CC: Yao Qi , "gdb-patches@sourceware.org" , "xdje42@gmail.com" Subject: RE: GDB 8.0 release/branching 2017-03-20 update Date: Thu, 06 Apr 2017 14:40:00 -0000 Message-ID: <9676A094AF46E14E8265E7A3F4CCE9AF3C134157@IRSMSX106.ger.corp.intel.com> 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> In-Reply-To: <20170331160246.xjlqgrrkayprdmba@adacore.com> dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00145.txt.bz2 Hi all, > Tim, are you OK with the result of this discussion, as well? I'm back and have read the mails you all wrote about this topic. Let me summarize to make sure I understand everything correctly. 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 =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). gdb.RecordInstruction (gdb.Instruction): int pc buffer data str decode int size int error gdb.Symtab_and_line sal bool is_speculative =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 ... =09 Created by other Python interfaces, e.g. a function that dissasembles target memory. gdb.RecordFunctionSegment: gdb.Symbol symbol int level gdb.RecordInstruction[] instructions gdb.RecordFunctionSegment up gdb.RecordFunctionSegment prev gdb.RecordFunctionSegment next =09 Renamed from "gdb.BtraceFunctionCall" to better fit the general scheme. 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). =09 Correct so far? 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 objects = are the same, nevertheless a comparison with "=3D=3D" does not yield "True" bec= ause they represent, well, two different instances of execution of that instruction. Keeping the "number" attribute in would show the user, why those objects ar= e not equal. Therefore I propose to retain the "number" attribute in "gdb.RecordInstruction" and for symmetry in "gdb.RecordFunctionSegment" as = well. Markus and I further discussed how we handle gaps or other errors in the tr= ace 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.RecordInstruc= tion" 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 =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". The user needs to distinguish between instructions and gaps somehow anyway,= 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 Please let me know if you agree with this so I can get to work as soon as possible. Regards, Tim > -----Original Message----- > From: Joel Brobecker [mailto:brobecker@adacore.com] > Sent: Friday, March 31, 2017 6:03 PM > To: Metzger, Markus T > Cc: Yao Qi ; Wiederhake, Tim > ; gdb-patches@sourceware.org; > xdje42@gmail.com > Subject: Re: GDB 8.0 release/branching 2017-03-20 update >=20 > > Tim, are you OK with the result of this discussion, as well? > > > > Joel, do we have a week or so for Tim to send a patch? >=20 > We do (I am going to be away all of next week). After that, let's cut the > branch no matter what, and backport if necessary. > I'd like to start soon, so as to give time for stabilization if needed. >=20 > -- > Joel 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