From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2393 invoked by alias); 21 Oct 2009 00:22:16 -0000 Received: (qmail 2383 invoked by uid 22791); 21 Oct 2009 00:22:15 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Oct 2009 00:22:11 +0000 Received: (qmail 7280 invoked from network); 21 Oct 2009 00:22:08 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 21 Oct 2009 00:22:08 -0000 From: Pedro Alves To: Michael Snyder Subject: Re: [RFA] Expand "info record" Date: Wed, 21 Oct 2009 00:22:00 -0000 User-Agent: KMail/1.9.10 Cc: "gdb-patches@sourceware.org" , Hui Zhu References: <4AD358E7.50009@vmware.com> <200910202154.04566.pedro@codesourcery.com> <4ADE38DA.8040803@vmware.com> In-Reply-To: <4ADE38DA.8040803@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910210122.06549.pedro@codesourcery.com> X-IsSubscribed: yes 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 X-SW-Source: 2009-10/txt/msg00484.txt.bz2 On Tuesday 20 October 2009 23:25:30, Michael Snyder wrote: > >> + /* Display instruction number for last instruction in the log. */ > >> + printf_filtered (_("Highest recorded instruction number is %llu.\n"), > >> + record_insn_count ? record_insn_count - 1 : 0); > > > > Why the conditional subtraction? > > Because I don't want it to say "-1". Okay, that much is obvious, but how can you reach here with record_insn_count == 0, given that you check if you have a log at all a bit above? > > Given this post inc: > >> + rec->u.end.insn_num = record_insn_count++; > > No, the post inc implies that the count is actually one greater > than the last insn that used it. Yes? Yes. > > Could you add a comment to record_insn_num and > > record_insn_count's definitions explaining what they are and > > how they're different, if it doesn't become obvious? > > Yep, done, see attached. Thanks. May I add that I think it's a shame that "info record" doesn't distinguish precord not being active from no log yet: (gdb) info record Process record is not active, or there is no log yet. Max logged instructions is 200000. I played with the patch 5 minutes, and I immediately felt that this bit not having an else branch was surprising: /* If we are not at the end of the log, display where we are. */ if (record_list->next != NULL && record_list->type == record_end) printf_filtered (_("Current instruction number is %s.\n"), pulongest (record_list->u.end.insn_num)); E.g.: (top-gdb) info record Lowest recorded instruction number is 14. Current instruction number is 17. Highest recorded instruction number is 18. Log contains 5 instructions. Max logged instructions is 5. (top-gdb) si No more reverse-execution history. 0x00007ffff7df3e1e in ?? () from /lib64/ld-linux-x86-64.so.2 (top-gdb) info record Lowest recorded instruction number is 14. Highest recorded instruction number is 18. Log contains 5 instructions. Max logged instructions is 5. (top-gdb) Can't we explicitly say that we're in recording/live vs replay mode, or something? -- Pedro Alves