From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17193 invoked by alias); 21 Dec 2012 19:12:27 -0000 Received: (qmail 17184 invoked by uid 22791); 21 Dec 2012 19:12:26 -0000 X-SWARE-Spam-Status: No, hits=-6.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 Dec 2012 19:12:18 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qBLJCEJe007599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Dec 2012 14:12:14 -0500 Received: from host2.jankratochvil.net (ovpn-116-39.ams2.redhat.com [10.36.116.39]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qBLJC6bo026762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 21 Dec 2012 14:12:09 -0500 Date: Fri, 21 Dec 2012 19:12:00 -0000 From: Jan Kratochvil To: "Metzger, Markus T" Cc: "palves@redhat.com" , "tromey@redhat.com" , "kettenis@gnu.org" , "gdb-patches@sourceware.org" , "markus.t.metzger@gmail.com" Subject: Re: [patch v6 00/12] branch tracing support for Atom Message-ID: <20121221191205.GA341@host2.jankratochvil.net> References: <1355760101-26237-1-git-send-email-markus.t.metzger@intel.com> <20121218091953.GF8054@host2.jankratochvil.net> <20121218135437.GA16636@host2.jankratochvil.net> <20121220071726.GA26625@host2.jankratochvil.net> <20121220112955.GA1420@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-12/txt/msg00775.txt.bz2 On Thu, 20 Dec 2012 16:20:13 +0100, Metzger, Markus T wrote: > My use case is to start with looking at the last 20 or so instructions. If > that's not enough, I want to look at the next 20. This would not be > supported by just adding "record list last ". I believe the current "view" style command of btrace should behave like normal "list" for the native GDB behavior. "btrace 2" shows: (gdb) btrace 2 0x000000000048bda0 : jmpq *0x17a599a(%rip) # 0x1c31740 (gdb) 0x000000000048bda0 : jmpq *0x17a599a(%rip) # 0x1c31740 (gdb) But then hitting just enter does not go further (to "btrace 3"), it repeats still the same output. In such case there should have been at least "dont_repeat ();". But I believe it would be more convenient to list the next btrace records. "btrace list" behaves the same, repeating the same content. And after "btrace list 1-9" one has to add the numbers to display "btrace list 1-19", single newline could advance on its own. "btrace list -" could go backwards, "btrace list" forward - like the "list" command does. But here is the question of positive/negative numbers direction, discussed below. I am fine with changing the cosmetic issues above in an additional patchset, as long as it is all done before the next release 7.6. > I wanted to keep the numbering of record/replay. That's why I added those > variables to be able to express what I want. > > Personally, I find the opposite numbering, i.e. from newest to oldest, more > intuitive and more useful, since I'm typically more interested in the tail > of the trace than the head. I agree one is interested in the tail but there is at least the established standard of "record" numbering direction. (+FYI I find the existing "record" direction more logical myself.) > Is the instruction number used anywhere outside "record goto"? >From record.c also in "info record" and for bookmarks ("info bookmark", "goto-bookmark" etc.). > > Probably not at all. Just there should remain the same to_resume/to_wait > > hooking. > > I'm not familiar with the implementation. I would expect, though, that it > won't be enough to implement to_resume and to_wait hooks. I would rather > expect that I will need to implement new stepping commands. The idea of the "record" implementation is that the same standard stepping commands work the same for "record" history, by emulating the target events. So that even new commands/features will work with the existing "record" implementation. to_wait updates real hardware registers/memory when moving in history so "everything just works". > I further expect that I would need to replace frame unwinding. Just to provide another unwinder, besides the several existing ones. Some unwinders are dwarf2_frame_unwind, inline_frame_unwind, dwarf2_tailcall_frame_unwind, then the hardware ones like i386_frame_unwind. The other possibility is to use existing unwinder (typically dwarf2_frame_unwind) and simulate memory as if it had the simulated/expected frames pointers; but for various reasons I do not find it right for btrace unwinding - as it already needs to know how the frame looked at that point, so I find cleaner to create the appropriate GDB frame structures instead of faking the target memory so that the existing unwinders create them that way. > For all other commands, I can > only hope that gdb is OK with a target that can read (not write) RIP but no > other register and that can access only code memory. GDB accesses stack memory each time, so the virtual btrace unwinder would need to be really ahead of all the other unwinders so that it prevents such accesses. GDB also inserts/removes breakpoints each time, this could be reused from record.c and its record_insert_breakpoint / record_remove_breakpoint. ("set breakpoint always-inserted on" reduces these accesses but it is not a default yet.) Then it could work I hope, "set debug target 1" shows the accesses. I believe one could rather just ask user Do you really want to read possibly stale memory? (y or n) or possibly just to print each time warning: The reported memory content may be stale! as one may want to print just some global variable when already reverse-stepped in a btrace history. Doing some "bookmark", "continue", "print errno", "goto-bookmark 5" may be too inconvenient. Thanks, Jan