From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2190 invoked by alias); 1 Feb 2013 14:18:47 -0000 Received: (qmail 2151 invoked by uid 22791); 1 Feb 2013 14:18:44 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS 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, 01 Feb 2013 14:18:37 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r11EIa26024432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Feb 2013 09:18:36 -0500 Received: from host2.jankratochvil.net (ovpn-116-88.ams2.redhat.com [10.36.116.88]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r11EITkQ018031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 1 Feb 2013 09:18:32 -0500 Date: Fri, 01 Feb 2013 14:18:00 -0000 From: Jan Kratochvil To: "Metzger, Markus T" Cc: "markus.t.metzger@gmail.com" , "gdb-patches@sourceware.org" Subject: Re: record-btrace Message-ID: <20130201141829.GA24703@host2.jankratochvil.net> References: <20130129095303.GA12614@host2.jankratochvil.net> <20130129153617.GA28655@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: 2013-02/txt/msg00006.txt.bz2 On Thu, 31 Jan 2013 16:38:43 +0100, Metzger, Markus T wrote: > The problem I have with "target record" is that the sub-commands are added in > add_target, one per added target. Would it be OK to export targetlist so I can add > an alias for target "record-full"? Or is it OK to just drop target "record"? OK, let's export targetlist, with some comment it should not be normally used. > If we dropped target record, we would break backwards compatibility. With eclipse-cdt-8.1.0-1.fc17.x86_64 I see it uses command "record" and not "target record". > There's a single test in gdb.mi that would need to be adjusted, but I would > also expect that GUIs would be broken. OK, both "record" and "target record" can be kept compatible, I do not mind, you are right it may cause front ends compatibility issue. > On a similar matter, I renamed the existing "set/show record" subcommands by > prepending "full-", i.e. "insn-number-max" becomes "full-insn-number-max". Could it be a prefix command? "set record full insn-number-max" etc. To match "record full" (vs. "record btrace"). > This does not break any tests but would affect scripts and MI. There should be aliases with deprecate_cmd during such changes, deprecate_cmd also ensures it does not get -completed anymore. > For record-btrace and record-full, to_record_list will be quite different. For all > other targets, it will be NULL. > > We could share to_disconnect, to_detach, to_kill, and to_mourn_inferior. They > are just forwarding the request after unpushing the record target. > > I made the "record stop" command generic. It searches for a record target > beneath the current and unpushes the first it finds. I could do something > similar for the above. It looks OK to me, it would be better to see the code. > There's a record_changed notifier that is called in to_open and in the stop > command. Why is it not called in to_close instead of in the stop command? to_close is a bit dangerous that the target is no longer on stack, as documented in unpush_target. So maybe record_changed could want to do something with the record traget yet. But with the currently only listener MI it should work even from to_close. > As long as you know what you are doing, it's convenient to be able to read > variables that you know have not changed. You need to be very careful, though, > to consider also stack changes when you reverse-step into a different function. > Things get worse if the compiler generates location lists. As there should be the custom unwinder blocking unwind the current frame won't be found there to access local variables, they should print an error. > > > I can do the CLI warning as first step. Will this warning also be available > > > via MI? > > > > It will be printed as general GDB output record but at least Eclipse CDT users > > won't notice it. It gets displayed only after selecting Debug window -> "gdb" > > and then it is in the displayed window "Console" as a "warning: ..." text. > > We should maybe make this configurable so GUIs will not show wrong data. I believe it is up to GUI to handle it somehow specially. The GUI knows it is currently operating in history, Eclipse already has special support for "record". Thanks, Jan