From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7056 invoked by alias); 29 Jan 2013 11:05:05 -0000 Received: (qmail 7043 invoked by uid 22791); 29 Jan 2013 11:05:04 -0000 X-SWARE-Spam-Status: No, hits=-7.9 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 mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Jan 2013 11:04:56 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 29 Jan 2013 03:04:55 -0800 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga002.jf.intel.com with ESMTP; 29 Jan 2013 03:04:54 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.82]) by IRSMSX104.ger.corp.intel.com ([169.254.5.20]) with mapi id 14.01.0355.002; Tue, 29 Jan 2013 11:03:41 +0000 From: "Metzger, Markus T" To: Jan Kratochvil CC: "markus.t.metzger@gmail.com" , "gdb-patches@sourceware.org" Subject: RE: record-btrace Date: Tue, 29 Jan 2013 11:05:00 -0000 Message-ID: References: <20130129095303.GA12614@host2.jankratochvil.net> In-Reply-To: <20130129095303.GA12614@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/msg00679.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Tuesday, January 29, 2013 10:53 AM Hi Jan, Thanks for the quick reply! > On Mon, 28 Jan 2013 17:13:59 +0100, Metzger, Markus T wrote: > > 1. add a new command "record-btrace" that pushes a new >=20 > "record btrace", there are already subcommands of "record". >=20 > It would be unconvenient to have some subcommands as "record-ABC" and som= e as > "record DEF" wrt tab-completion. OK. So the targets will be called "record-full" and "record-btrace" and can= be used directly with the "target" command; the "record" command will use = sub-commands. We thus have: "target record-full" "target record-btrace" "target record" aliases "target record-full" "record full" "record btrace" " record" aliases "record full" If we now want to add LBR-based branch tracing, we could either change reco= rd-btrace to record-btrace-bts and add record-btrace-lbr or make "bts" and = "lbr" configuration options of record-btrace. The former leads to very long= names and commands; the latter requires "set/show record" commands to be u= sable even if no or the wrong record target is currently active. > > The existing brace target-ops and also the btrace RSP packets will need= to > > remain since I still need to configure branch tracing on the target. Wi= thout > > them (i.e. the functionality hard-coded in record_btrace_target_ops), > > I don't see how I could handle the remote case. Record_btrace_open will= call > > target_btrace_enable to do the actual work. It will fail if one of the > > btrace enable calls fails. >=20 > OK; therefore two btrace struct target_ops for linux-nat.c vs. remote.c a= nd one > btrace struct target_ops for record btrace (vs. full). If you're OK to keep the btrace target_ops methods, we shouldn't need separ= ate target_ops structs for native and remote. The btrace methods will be su= pplied by the native and remote targets. The record-btrace target will be o= n top and use the btrace methods from the target beneath. > > I may need to allow reading memory for read-only dynamic sections so th= at at > > least "disas" works. Does gdb maintain a dynamic section map? Could gdb= be > > taught to read this memory from a file, instead? >=20 > I would not be too strict with accessing the inferior memory. I understa= nd > that the memory content may be different when GDB is in the btrace histor= y 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) war= ning > if one accesses a read/write memory during command execution. >=20 > Forbidding any memory access may be correct but it may be pain for the us= ers. I would find this very confusing. Stack and heap might not be available any= more - or might contain different objects. I can do the CLI warning as first step. Will this warning also be available= via MI? Do you know whether gdb is reading memory for some internal logic? > > When they reach the end of the trace, they turn into normal stepping > > commands, i.e. I will forward to_resume and to_wait to the target benea= th. > > This should implicitly continue other threads depending on the execution > > mode. When the target stops next time, the tracing positions for all st= opped > > threads will be reset - I won't be able to find the old position in the= new > > version of the trace. This behavior might be somewhat surprising if you > > switched threads while traversing the history. >=20 > I would rather print an error in such case - that one should switch to the > thread with position in history and roll it back to the current position > before the whole process can be resumed by the target beneath. That can easily become quite annoying if you have several threads. We could= query the user if he wants to continue even though some threads are somewh= ere in the history. How would this work for MI? Is scheduler-locking implemented by the step commands or by the target's to= _resume and to_wait functions? I have only considered a single inferior, so far. Regards, 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