RE: [patch v4 03/24] btrace: change branch trace data structure

["Metzger, Markus T" <markus.t.metzger@intel.com>]

> -----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 fully
> > > > > 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, seeing
> 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 extend
> 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.
> 
> (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.
> 
> 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 for
> 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 very old
> records and it is inconvenient for users to renumber the events all the time.

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 frequent
interrupts plus the time it takes for downloading and processing the trace.


> > The lowest recorded instruction is always zero for record-btrace.
> 
> 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