From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17546 invoked by alias); 31 Jan 2013 15:38:56 -0000 Received: (qmail 17352 invoked by uid 22791); 31 Jan 2013 15:38:53 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mga03.intel.com (HELO mga03.intel.com) (143.182.124.21) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 31 Jan 2013 15:38:48 +0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 31 Jan 2013 07:38:46 -0800 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by AZSMGA002.ch.intel.com with ESMTP; 31 Jan 2013 07:38:45 -0800 Received: from irsmsx151.ger.corp.intel.com (163.33.192.59) by IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 31 Jan 2013 15:38:44 +0000 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.82]) by IRSMSX151.ger.corp.intel.com ([169.254.4.144]) with mapi id 14.01.0355.002; Thu, 31 Jan 2013 15:38:43 +0000 From: "Metzger, Markus T" To: Jan Kratochvil CC: "markus.t.metzger@gmail.com" , "gdb-patches@sourceware.org" Subject: RE: record-btrace Date: Thu, 31 Jan 2013 15:38:00 -0000 Message-ID: References: <20130129095303.GA12614@host2.jankratochvil.net> <20130129153617.GA28655@host2.jankratochvil.net> In-Reply-To: <20130129153617.GA28655@host2.jankratochvil.net> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable 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-01/txt/msg00749.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Tuesday, January 29, 2013 4:36 PM > > "target record-full" > > "target record-btrace" > > "target record" aliases "target record-full" > > "record full" > > "record btrace" > > " record" aliases "record full" >=20 > Maybe "record" and "target record" could already print an error about the > command being deprecated; but that is a subtle difference, I do not mind. I made "record" default to "target record-full", without a deprecation noti= ce. 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"? If we dropped target record, we would break backwards compatibility. There'= s a single test in gdb.mi that would need to be adjusted, but I would also expe= ct that GUIs would be broken. 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". This does not break any tests but would affect scripts and MI. If we wouldn= 't do that, on the other hand, it would look quite odd when we started adding btrace-related configuration options. > > If we now want to add LBR-based branch tracing, we could either change > > record-btrace to record-btrace-bts and add record-btrace-lbr or make "b= ts" > > and "lbr" configuration options of record-btrace. >=20 > If we had LBR I believe it should be always enabled by default - when > available - as it has AFAIK no measurable performance disadvantage. So t= he > way of enabling it explicitly should not matter much. LBR does not work together with BTS. We can either have one or the other. > [detail] > Initialization of the common fields like to_record_list could be moved to= some > common initialization function like i386_use_watchpoints(). 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. Th= ey 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. 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? > > > I would not be too strict with accessing the inferior memory. I unde= rstand > > > that the memory content may be different when GDB is in the btrace hi= story but > > > most of the memory including read/write variables a user may want to = read will > > > be the same. > > > > > > It could rather just print a CLI (the default command-line interface)= warning > > > if one accesses a read/write memory during command execution. > > > > > > Forbidding any memory access may be correct but it may be pain for th= e users. > > > > I would find this very confusing. Stack and heap might not be available= any > > more - or might contain different objects. >=20 > The problem is if you are in history and you want to print a variable - s= hould > you "continue" back to the current state, read the variable and move back? 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, thou= gh, to consider also stack changes when you reverse-step into a different funct= ion. Things get worse if the compiler generates location lists. > > I can do the CLI warning as first step. Will this warning also be avail= able > > via MI? >=20 > 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. Thanks, Markus. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052