From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24303 invoked by alias); 20 Dec 2012 09:14:17 -0000 Received: (qmail 24290 invoked by uid 22791); 20 Dec 2012 09:14:16 -0000 X-SWARE-Spam-Status: No, hits=-7.7 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 20 Dec 2012 09:14:10 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 20 Dec 2012 01:14:09 -0800 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga002.fm.intel.com with ESMTP; 20 Dec 2012 01:14:07 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.95]) by IRSMSX103.ger.corp.intel.com ([169.254.3.74]) with mapi id 14.01.0355.002; Thu, 20 Dec 2012 09:13:27 +0000 From: "Metzger, Markus T" To: Jan Kratochvil 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 Date: Thu, 20 Dec 2012 09:14:00 -0000 Message-ID: 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> In-Reply-To: <20121220071726.GA26625@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: 2012-12/txt/msg00737.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Thursday, December 20, 2012 8:17 AM =20 > > One typical command that I do after stopping is "btrace list 1-8" to get > > a rough idea where I came from. > > Translated to record, this would become "info record" followed by "reco= rd > > list 18914-18989". >=20 > One can make extension of the syntax to give "record list last 8" > or even just "record last 8". GDB even provides "alias" command to even > shorten it for specific user to just "last 8" etc. I will think about the "record list" and "record disas" command syntax. How do you like temporarily adding debugger variables "$end", "$start", and= "$here" and accepting the same syntax that list and disas accept? I don't = know how difficult that will be to implement, though. > > I'm afraid, though, that it will not be that simple and that we > > will end up doing the full integration and also some changes to > > record/replay in the process, before there will be any support for bran= ch > > tracing in gdb. >=20 > AFAIK currently any Intel CPUs available in the market do not provide BTS > anyway. I doubt Atom CPUs are used by developers and/or enterprise > troubleshooting. It would be a different question if there was a way to = force > use of the buggy Nehalem BTS which should be good enough in common cases > (maybe) but there is no such option currently available. Atom might be relevant for Android developers. A force option would have been possible had we not disabled it in the kerne= l. > > I played around with record/replay and reverse debugging a bit. One thi= ng > > that I did not understand is how multi-threading is handled. >=20 > It is not, it is a bug. One should use "set scheduler-locking on". > In reality one cannot record too long sequences due to performance reason= s so > one does not want to record multiple threads anyway. Ah. I always wondered whether GDB is able to step individual threads. In that case, branch tracing would already be an improvement over record/re= play for multi-threaded programs. Btw, is anybody actively working on fixing record/replay? > > I see how I could add a command "record config" that takes "replay" and > > "bts" as arguments and switches between the two. >=20 > Currently one uses just "record" to start the full-recording. I was expe= cting > it could print an error and one would use in newer versions of GDB > "record btrace" vs. "record full" or something like that. "record config" > does not seem convenient enough for daily use to me. OK. > > I also see how I could > > implement "record disassemble", "record list", and "record goto" for BT= S. > > The commands would check the config and go one way or another - quite d= irty, > > but the only thing doable without spending lots of effort. >=20 > I do not see anything dirty there but otherwise I agree Good. > "would check" should be implemented by pushing "target_ops" from record.c= vs. > pushing "target_ops" from btrace.c to the GDB target stack when starting = the > record session, so that the target methods get used automatically when > target_* dispatchers get called. For "goto", "list", and "disas", I don't need to overwrite any target ops. > > I would simply mark other "record" commands as not supported for the BTS > > configuration. Since I'm not actually moving the location of any thread= , all > > other gdb commands will operate on the location the thread has been sto= pped. > > Only "record disassemble" and "record list" would work on the current > > instruction for the current thread. And each thread would have a differ= ent > > number of instructions as well as current instruction. I do hope that a= ll > > this is acceptable to all maintainers. >=20 > It is important that BTS would also modify inferior PC so that normal com= mands > like "list" work on the current BTS position and "step" or "reverse-step"= move > in the BTS position list. That would be the second step. Otherwise, I will really end up implementing= the entire record/replay machinery for branch tracing. Regarding stepping, reverse-next and reverse-finish will have to operate on= a fake call stack we compute from collecting calls and rets in the branch = trace. As will next and finish when inside the history. I don't know how mu= ch I will be able to reuse from the record/replay implementation. All stepping commands on branch trace will further only affect the current = thread, independent of scheduler-locking. This will be a major difference t= o record/replay once that is fixed. =20 > > There's one thing (well, one that I am currently aware of) I don't know= how > > to do: enable/disable. >=20 > Current full-tracing uses "record" (for BTS "record btrace") and "record = stop" > is also already used. >=20 >=20 > > Due to the high cost of branch tracing, it makes > > sense to allow selective tracing of one or more threads. For one, it is= not > > guaranteed that all threads in a process can be traced - you may run ou= t of > > resources at some point. Also not tracing all threads may allow you to = use > > bigger buffers for the threads that are traced. >=20 > "record btrace" can parse parameters like "btrace enable" does. OK. > > At the same time, I wanted some always-on functionality so I didn't hav= e to > > repeatedly enable tracing. I therefore added two different versions: "b= trace > > enable [all, ]" and "btrace enable auto". Record/replay uses ano= ther > > target on top of the current. >=20 > btrace also needs to - so that "step" and "reverse-step" work there as th= ey > catch target_resume/target_wait. This will not be enough (see above). > > It needs to be enabled for a running process > > each time and it does not allow selective enabling/disabling per thread= . If > > I just followed the "target record" command, I would lose the selective > > enabling as well as the automatic enabling - and I would risk that not = all > > threads will be traced when running out of resources. Do you have an id= ea > > how this could be done? >=20 > Going to look at it today. Thanks. Btw, are you the record/replay maintainer? 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