From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95843 invoked by alias); 7 Apr 2017 15:19:15 -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 94970 invoked by uid 89); 7 Apr 2017 15:19:14 -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=Imagine 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 15:19:12 +0000 Received: by mail-wr0-f182.google.com with SMTP id g19so67653494wrb.0 for ; Fri, 07 Apr 2017 08:19:13 -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=a4b+cA1TXWdIcJHkCHIfOcZtYjCJdHVcaeTDdXcsa34=; b=dMAHMs+Ox+ZMje0OJkNTafZbSwULAsDoF8ZYVL1ia1EzZhZHyKf5xAvFSwYdCoWiLa n1LCAeW7H0p+kwURtFLt8TwCnaK2zV5MamtdfyUT8upgXu+8b1Un6ih4SF5wfwyJt02K ONV7YZKtQT4pTlrYw9rKUG/qlVJ0qjYUDqr2FuauHN6TWPWwA5F14Y6BNOPRKu0x6vWn 9Z1MXmhbih7TsqyXi4O4o58VlxClm2zyvLnMMvu0O5nWgaX2/z6x5wyiCNZ7ToMzF0nx Hw/i7k1xXmCxy6f1F8UBSE2ubXXCqyfEfF/I+NU3ZeMNrWRtfXPXDJWIcCx59HquX0qZ nZ8g== X-Gm-Message-State: AFeK/H2HHXOpKK6jaj94wjy2UFao2Grfqs+KEnJssUBP1unzCWSTibnshMJGbICFzDs8hQ== X-Received: by 10.223.163.75 with SMTP id d11mr38085789wrb.127.1491578351906; Fri, 07 Apr 2017 08:19:11 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id p7sm6367180wrc.19.2017.04.07.08.19.09 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 07 Apr 2017 08:19:10 -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> <86fuhkk58b.fsf@gmail.com> <9676A094AF46E14E8265E7A3F4CCE9AF3C1342D2@IRSMSX106.ger.corp.intel.com> Date: Fri, 07 Apr 2017 15:19:00 -0000 In-Reply-To: <9676A094AF46E14E8265E7A3F4CCE9AF3C1342D2@IRSMSX106.ger.corp.intel.com> (Tim Wiederhake's message of "Fri, 7 Apr 2017 11:53:02 +0000") Message-ID: <8660igjled.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/msg00171.txt.bz2 "Wiederhake, Tim" writes: > Imagine you have some code like this: > > void > a () > { > /* some code */ > } >=20=20 > void > b () > { > /* some code */ > a (); > /* some code */ > } > > Then the trace for a call to function "b" would generate three function c= all > segments: One for the code in "b" before the call to "a", one for the cod= e in > "a" and one for the code in "b" after the call to "a" returned. > > The "next" attribute in the first function segment points to the third fu= nction > segment and likewise the "prev" attribute in the third function segment p= oints > to the first function segment. For the second function segment the "up" > attribute points to the first function segment. > > "Segment" is used instead of "Call" throughout the btrace code to avoid t= he > impression that one function segment contains the whole recorded data for= a > function call whereas it only contains a part of it. I believe we should > continue this terminology in Python. >=20=20 OK, "Segment" is fine with me. >> > 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 >> > >> I don't like using exception for control flow. > > The above code with the "error" attribute still in place would look like = this: > > r =3D gdb.current_recording() > for insn in r.instruction_history: > if not insn.error: > print insn.pc, insn.sal > else: > print insn.error_message > > The user has to take care about the rare possibility of a gap occurring i= n the > trace. In the latter case, they have to explicitly check that the instru= ction > they look at is not a gap, which is easy to forget and will lead to stran= ge > results as the "pc", "sal", "data", "size" and so on attributes of a gap = do not > contain meaningful data. > > In the former example, the exception is raised by accessing "insn.pc", an > attribute that does not exist for a gap. I expect the usual code for the > "except" path to just contain a "pass" or "continue" statement. I just p= rinted > the error_message in the example to showcase how this situation would be = handled > if a user desired so. > > If you wanted to write this example without handling exceptions, you coul= d do > so as well: > > r =3D gdb.current_recording() > for insn in r.instruction_history: > print getattr(insn, "pc", "has no address"), getattr(insn, "sal", "has n= o sal") > > And even if the user simply wrote: > > r =3D gdb.current_recording() > for insn in r.instruction_history: > print insn.pc, insn.sal > > there are two cases: The trace contains no gaps (common), or the trace co= ntains > gaps (uncommon). If the trace did not contain any gaps, the code works as > expected. If the trace contained gaps, Python will raise an exception po= inting > in the right direction of the problem. > > If instead we continued to offer the "error" attribute and the user forgo= t to > check, the code would silently fail and produce wrong results. I believe= the > option where we fail loud and clear is favorable over the silently wrong = result. > >> If I understand "gap" >> correctly, it is caused something interrupt the tracing. > > There might be other causes as well, such as overflows, decoding errors, = etc. > Again, ideally the trace contains no gaps at all, but rarely it may conta= in one > or more gaps interleaved with the regular instructions. > Is it possible that gap is not caused by error? As I said in previous mail, user may want to trace a block of instructions, instructions out of this range are regarded as gap. My point is that we need to define a general reason in gap instead of error. >> I'd like to >> change the interface like this, >>=20 >> gdb.InstructionHistory >> a list of gdb.RecordInstruction >> gdb.RecordGap (or gdb.RecordStopReason) >>=20 >> 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). >>=20 >> gdb.Record.instruction_history returns a list of gdb.InstructionHistory. > > Just to make sure: You propose that gdb.Record.instruction_history return= s a > list of partial lists, and each partial list contains the reason why that > particular partial list was interrupted / stopped, correct? Yes. > > Generating this list of lists would be quite expensive as we have to go o= ver the > whole list of instructions (that at least for btrace internally /is/ a li= st of > instructions interleaved with gap objects), count the gaps and save their > position to know the length of this list of lists and the start and end o= f the > individual sub lists. With the explanation above how to do this without = having > to care about exceptions, would you agree on keeping the list one-dimensi= onal, > with instructions and rarely gaps interleaved as-is? OK, that is fine to me. --=20 Yao (=E9=BD=90=E5=B0=A7)