From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4905 invoked by alias); 19 Dec 2012 09:59:56 -0000 Received: (qmail 4895 invoked by uid 22791); 19 Dec 2012 09:59:55 -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 mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 19 Dec 2012 09:59:44 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 19 Dec 2012 01:59:41 -0800 X-ExtLoop1: 1 Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159]) by orsmga002.jf.intel.com with ESMTP; 19 Dec 2012 01:59:40 -0800 Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by IRSMSX104.ger.corp.intel.com (163.33.3.159) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 19 Dec 2012 09:59:38 +0000 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.95]) by IRSMSX152.ger.corp.intel.com ([169.254.6.36]) with mapi id 14.01.0355.002; Wed, 19 Dec 2012 09:59:38 +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: Wed, 19 Dec 2012 09:59: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> In-Reply-To: <20121218135437.GA16636@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/msg00686.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Tuesday, December 18, 2012 2:55 PM > In general I agree. Just they should be moved under the "record" prefix. > Command "btrace" then should be renamed to some "record disassemble". I see how this could be done. This would require the btrace command to work= on instructions, though, instead of blocks. 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 "record l= ist 18914-18989". After the next step, this would become " info record" followed by "record l= ist 18917-18993". That's clumsy. I guess what we would want is something like "record list end-80, +80". Alt= hough this gives the impression that "end" or "start" can be used in expres= sions. Not sure if we want that generality. We would need to rename them to= $end and $start, respectively, to avoid name clashes. Btw, "record goto" silently discards junk following "end" or "start" and "h= elp record goto" does not mention "start" or "end". On the other hand, it s= eems to accept arbitrary expressions as argument. > > Given the different use cases, it would make sense to establish two set= s of > > commands for all kinds of control-flow tracing/replay: one for viewing = and > > one for navigating. In a first step, BTS tracing will only implement the > > former and "record" will only implement the latter. In a second step, > > "record" could implement the viewing commands, and in third step, BTS > > tracing can implement the navigation commands. > > > > Would that be OK with you? >=20 > I believe you a heading for an approval of this patchset as is, so that t= he > unification can be implemented in an add-on patch series. This patch series is sitting around for a long time, already. Yes, I would = like to see it approved to show that there is progress. > I do not think the unification patch series will get checked-in soon enou= gh > for gdb-7.6. That means the currently defined commands will need to rema= in > backward comparible indefinitely in the future. So one should make the > commands syntax final already (there is deprecate_cmd but it is not good = to > plan its use). I don't know how strict gdb is with regards to backwards compatibility. I a= lso don't know how strict it needs to be. It would certainly be nice if we could just rename the btrace commands and = proceed. I'm afraid, though, that it will not be that simple and that we wi= ll end up doing the full integration and also some changes to record/replay= in the process, before there will be any support for branch tracing in gdb. > I believe the internal API will change a lot for the unification with rec= ord > backend/data so it seems to me a large part of the patch will need to get > replaced afterwards. >=20 > But I am OK with that if we at least make the commands unified with record > with some hope the backend functionality unification will come later. I played around with record/replay and reverse debugging a bit. One thing t= hat I did not understand is how multi-threading is handled. For exact replay, the interleaving of threads needs to be recorded. I would= thus expect a single "timeline" or "history" for all threads. Stepping com= mands that operate in replay mode may operate on a single thread, but they = should also move other threads as a side-effect. You should be able to see = this via "info threads" and also when switching to other threads. When I do "info record" in combination with switching threads, it seems as = if all threads would share a common history. They all have the same number = of instructions and the same current instruction. When I do reverse steppin= g, however, it seems as if I would only step a single thread. For each "rsi= " command, the current instruction is decremented by one and the location o= f the current thread changes. When I do "info threads", the location of oth= er threads does not change. When I switch to other threads, they are at the= location I left them. Yet when I do "info record" again, the current instr= uction is the same as it had been for the thread I stepped. The same curren= t instruction showed two different locations for the same thread. Comparing record/replay with BTS tracing, there is a fundamental difference= : record/replay needs a common history for all threads, whereas BTS has sep= arate histories for each thread and no means of correlating those histories= . Record/replay is per-process; branch tracing is per-thread. This is bound to cause problems when we're trying to share the same infrast= ructure internally. The commands will also behave differently depending on = whether record/replay or BTS is used. I hope that does not cause more confu= sion than a separate set of commands would. I see how I could add a command "record config" that takes "replay" and "bt= s" as arguments and switches between the two. I also see how I could implem= ent "record disassemble", "record list", and "record goto" for BTS. The com= mands would check the config and go one way or another - quite dirty, but t= he only thing doable without spending lots of effort. There's still the pro= blem of listing or disassembling the last n instructions/blocks (see above)= or listing +/- n from the current position. This would need to be added to= record/replay, as well. I would simply mark other "record" commands as not supported for the BTS co= nfiguration. Since I'm not actually moving the location of any thread, all = other gdb commands will operate on the location the thread has been stopped= . Only "record disassemble" and "record list" would work on the current ins= truction for the current thread. And each thread would have a different num= ber of instructions as well as current instruction. I do hope that all this= is acceptable to all maintainers. There's one thing (well, one that I am currently aware of) I don't know how= to do: enable/disable. Due to the high cost of branch tracing, it makes se= nse to allow selective tracing of one or more threads. For one, it is not g= uaranteed that all threads in a process can be traced - you may run out of = resources at some point. Also not tracing all threads may allow you to use = bigger buffers for the threads that are traced. At the same time, I wanted some always-on functionality so I didn't have to= repeatedly enable tracing. I therefore added two different versions: "btra= ce enable [all, ]" and "btrace enable auto". Record/replay uses anot= her target on top of the current. It needs to be enabled for a running proc= ess each time and it does not allow selective enabling/disabling per thread= . If I just followed the "target record" command, I would lose the selectiv= e enabling as well as the automatic enabling - and I would risk that not al= l threads will be traced when running out of resources. Do you have an idea= how this could be done? 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