From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3006 invoked by alias); 23 Sep 2013 06:54:09 -0000 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 Received: (qmail 2994 invoked by uid 89); 23 Sep 2013 06:54:08 -0000 Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Sep 2013 06:54:08 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_50,RDNS_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mga02.intel.com Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 22 Sep 2013 23:54:04 -0700 X-ExtLoop1: 1 Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga002.jf.intel.com with ESMTP; 22 Sep 2013 23:54:03 -0700 Received: from irsmsx153.ger.corp.intel.com (163.33.192.75) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 23 Sep 2013 07:54:02 +0100 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.69]) by IRSMSX153.ger.corp.intel.com ([169.254.9.47]) with mapi id 14.03.0123.003; Mon, 23 Sep 2013 07:54:02 +0100 From: "Metzger, Markus T" To: Jan Kratochvil CC: "gdb-patches@sourceware.org" , "Himpel, Christian" Subject: RE: [patch v4 03/24] btrace: change branch trace data structure Date: Mon, 23 Sep 2013 06:54:00 -0000 Message-ID: References: <1372842874-28951-1-git-send-email-markus.t.metzger@intel.com> <1372842874-28951-4-git-send-email-markus.t.metzger@intel.com> <20130818190426.GC24153@host2.jankratochvil.net> <20130912200927.GA29475@host2.jankratochvil.net> <20130921194413.GA20539@host2.jankratochvil.net> In-Reply-To: <20130921194413.GA20539@host2.jankratochvil.net> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2013-09/txt/msg00807.txt.bz2 > -----Original Message----- > From: Jan Kratochvil [mailto:jan.kratochvil@redhat.com] > Sent: Saturday, September 21, 2013 9:44 PM > > > > > Unrelated to this patch but the function > > > > > record_btrace_insn_history_from does not need to be virtualized. = It > > > > > does not access any internals of record-btrace.c, it could be ful= ly > > > > > implemented in the superclass record.c and to_insn_history_from > > > > > could be deleted. > > > > > > > > > > The same applies for record_btrace_call_history_from and > > > > > to_call_history_from. > > > > > > > > Both depend on the numbering scheme, which is an implementation > detail. > > > > They both assume that counting starts at 0 (at 1 in a later patch). > > > > > > > > This does not hold for record-full, where the lowest instruction may > > > > be bigger than zero. > > > > > > OK, one reason is that currently there is no implementation of these > > > methods for record-full: > > > (gdb) record instruction-history > > > You can't do that when your target is `record-full' > > > > > > The second reason is that while record-full can drop old record, seei= ng > only > > > the last window: > > > (gdb) set record full insn-number-max 10 > > > (gdb) record > > > (gdb) info record > > > Active record target: record-full > > > Record mode: > > > Lowest recorded instruction number is 1587. > > > Highest recorded instruction number is 1596. > > > Log contains 10 instructions. > > > Max logged instructions is 10. > > > > > > btrace backend does not seem to support such sliding window (the > kernel > > > buffer sliding is unrelated). GDB still stores in its memory all the= btrace > > > records and one cannot do anything like > > > (gdb) set record btrace insn-number-max 10 > > > > It's inherent in btrace. We only ever see the tail of the trace. We e= xtend > the > > recorded trace when the kernel buffer does not overflow between > updates. > > Otherwise, we discard the trace in GDB and start anew with the current = tail. >=20 > (gdb) set record full insn-number-max 3 > (gdb) record > (gdb) stepi > (gdb) stepi > (gdb) stepi > (gdb) info record > Active record target: record-full > Record mode: > Lowest recorded instruction number is 1. > Highest recorded instruction number is 3. > Log contains 3 instructions. > Max logged instructions is 3. > (gdb) stepi > Do you want to auto delete previous execution log entries when > record/replay buffer becomes full (record full stop-at-limit)?([y] or n) y > (gdb) info record > Active record target: record-full > Record mode: > Lowest recorded instruction number is 2. > Highest recorded instruction number is 4. > Log contains 3 instructions. > Max logged instructions is 3. >=20 > While 'record full' stores only the tail of selected size 'record btrace' > stores everything and one has to occasionally 'record stop' and 'record > btrace' > again otherwise GDB runs out of memory. At least this is what I expect f= or > long-term running inferiors, I do not have Haswell available to verify it. When you trace a long running inferior with record btrace, you will only get the tail of the trace - independent of how long you let it run. The trace is collected in a cyclic buffer by the h/w. When the inferior stops, GDB reads that buffer which corresponds to the tail of the inferior's execution trace. That is, GDB first tries to read the delta trace and try to stitch it to the old trace from the previous read. This only works as long as the cpu buffer does not overflow. In practice, this should work for single-stepping with the occasional next over relatively short functions. So if you keep on single-stepping for a very long time, you may indeed exhaust GDB's memory. I don't think that this is a real issue in practice, though. As soon as you next over a big function or continue the inferior, the h/w buffer will very likely overflow and you will again get the tail of the trace. GDB will implicitly discard the old trace. It doesn't know what happened between the old and the new trace. > With btrace one cannot select the tail size (there is nothing like > 'set record btrace insn-number-max 3'), perf_event_buffer_size() is > auto-detected, 4MB max. That's correct. I can't really come up with a good reason why you would want less trace. Maybe if you had a real big number of threads or were really just interested in the last handful of branches. > I try to explain the numbering ranges X-Y (and not just 1-Y) should apply= also > to record btrace, not just to record full. btrace also needs to drop ver= y old > records and it is inconvenient for users to renumber the events all the t= ime. It's impossible for btrace to keep track of the number of instructions that= have been executed, so far, without increasing the overhead tremendously. GDB would need to stop the debuggee before the trace buffer runs full and then process the trace and either store it or discard it. This means very frequ= ent interrupts plus the time it takes for downloading and processing the trace. > > The lowest recorded instruction is always zero for record-btrace. >=20 > Which may cause GDB memory many-MB overflow if one traces long-running > inferior, I guess. No. It means that GDB renumbers the instructions each time the trace buffer overflows. So zero (later changed to one) is always the first instruction that is available in the recorded execution history. 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