From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9309 invoked by alias); 28 Jan 2013 16:14:58 -0000 Received: (qmail 9298 invoked by uid 22791); 28 Jan 2013 16:14:56 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_SPAMHAUS_DROP,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,TW_EG X-Spam-Check-By: sourceware.org Received: from mga11.intel.com (HELO mga11.intel.com) (192.55.52.93) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Jan 2013 16:14:50 +0000 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 28 Jan 2013 08:14:49 -0800 X-ExtLoop1: 1 Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by fmsmga001.fm.intel.com with ESMTP; 28 Jan 2013 08:14:47 -0800 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.82]) by IRSMSX103.ger.corp.intel.com ([169.254.3.218]) with mapi id 14.01.0355.002; Mon, 28 Jan 2013 16:14:00 +0000 From: "Metzger, Markus T" To: Jan Kratochvil CC: "markus.t.metzger@gmail.com" , "gdb-patches@sourceware.org" Subject: record-btrace Date: Mon, 28 Jan 2013 16:14:00 -0000 Message-ID: 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/msg00672.txt.bz2 Hi Jan, I was interrupted by some other task. Now I'm switching back to btrace and = to your request for merging it with record. Let me try to recap what you're= asking for and sketch a preliminary plan for you to comment on. 1. add a new command "record-btrace" that pushes a new record_btrace_target= _ops onto the target stack. By default, this will enable branch tracing for= all existing and all new threads. Arguments may later be added to only ena= ble branch tracing selectively for some threads. This record_btrace_target_ops will be fairly empty in the first step. We do= n't support reverse execution, yet. The only effect should really be to pre= vent record and btrace from co-existing. 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. Withou= t them (i.e. the functionality hard-coded in record_btrace_target_ops), I d= on't see how I could handle the remote case. Record_btrace_open will call t= arget_btrace_enable to do the actual work. It will fail if one of the btrac= e enable calls fails. The target is global. The data (i.e. configuration, history), however, will= still be per-thread. I don't know how target record handles this. I was th= inking of keeping the btrace internal structure. If we're going to extend this in the future, say, by adding an LBR-based br= anch trace, this would be another record_btrace_lbr_target_ops that may sha= re some of the functions with the BTS-based record-btrace target. You mentioned that we should not pop that target when the process terminate= s to implement auto enabling for new processes. I'm not quite clear how tha= t will work. I always thought the target stack is newly setup for each proc= ess. I wonder how we can leave the topmost entry always on? 2. implement the standard "record" commands for this new record-btrace targ= et, i.e. "info record", "set/show record", "record goto", "record save", "r= ecord restore", "record stop", "record delete". The "set/show record" sub-commands won't make much sense for record-btrace.= On the other hand, we would need some other sub-commands to configure bran= ch tracing. Would I dynamically add and remove those (sub-)commands dependi= ng on which record target is currently active? I have not seen functions to= remove commands. Or would I need to put sub-command handling into a single= "set record" and "show record" command (i.e. do not use sub-commands)? The "info record" command makes sense for all record variants, but it will = show different information for each record target. Would I add a new target= -ops function for it? Or would I add a new struct record_ops to collect tho= se functions? The "record save/restore" commands won't be available. Needs more target-op= s or record-ops functions. The "record goto" and "record delete" commands will need to work on btrace = data structures, instead. Needs more target-ops or record-ops functions. I would essentially move those commands into a new file and implement some = record abstraction for them to work on. 3. add a new "record disas" sub-command to print the disassembly of the las= t instructions and iterate through the instruction history similar to the l= ist command. This will be disabled for target record and implemented for ta= rget record-btrace. I would add another target_ops or record_ops function to do the actual work= that is called from the "record disas" command. In a later step, this could be implemented for target record, as well. 4. add a new "record list" sub-command similar to "record disas" but listin= g the source lines that have been executed. 5. extend "record stop" to take parameters that allow selective disabling o= f branch tracing. Not sure if and how this will work with the existing targ= et record. 6. Implement reverse execution for record_btrace_target_ops: To_resume/to_wait: iterate through instruction history To_insert_breakpoint: maintain breakpoint list - don't forward to target To_fetch_registers: only support the instruction pointer register To_store_registers: not allowed To_xfer_partial: not allowed To_~_watchpoint: not allowed When I don't allow reading memory in target record, nothing works, anymore,= i.e. almost all gdb commands fail. When I don't allow fetching registers in target record, there seems to be n= o impact - I guess the regcache is up-to-date so we don't really need to as= k the target. When I do a single reverse stepping command, however, it fails and gdb beli= eves that the target is executing - nothing works, anymore. The first experiment is not very encouraging. Do you think this can be done= , at all? I may need to allow reading memory for read-only dynamic sections so that a= t least "disas" works. Does gdb maintain a dynamic section map? Could gdb b= e taught to read this memory from a file, instead? I may also need to replace the unwinder even though I'm not adding unwind s= upport, yet - just to prevent it from failing. Are unwinders global or can = a target add/remove unwinders? If unwinders can't be added/removed dynamica= lly, I would add an unwinder to target_ops that will, if present, precede a= ll other unwinders. Would that be OK? I would like to simulate the above two (i.e. allow access to read-only memo= ry and add a do-nothing unwinder) to see what issues we might be running in= to with a target record-btrace. Would you help me with that? Reverse- and subsequent forward- stepping command should target the current= thread only as long as the thread is inside the recorded execution history= . I hope that's what I get when I overwrite to_resume and to_wait and only = consider the current thread. When they reach the end of the trace, they turn into normal stepping comman= ds, i.e. I will forward to_resume and to_wait to the target beneath. This s= hould implicitly continue other threads depending on the execution mode. Wh= en the target stops next time, the tracing positions for all stopped thread= s will be reset - I won't be able to find the old position in the new versi= on of the trace. This behavior might be somewhat surprising if you switched= threads while traversing the history. 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