Re: [rfc] btrace: change record instruction-history /m

[Eli Zaretskii <eliz@gnu.org>]

> From: "Metzger, Markus T" <markus.t.metzger@intel.com>
> CC: "palves@redhat.com" <palves@redhat.com>, "gdb-patches@sourceware.org"
> 	<gdb-patches@sourceware.org>
> Date: Mon, 17 Aug 2015 07:15:37 +0000
> 
> > > >> Change record instruction-history /m to use its own simple source
> > interleaving
> > > >> algorithm.  The most important part is that instructions are printed in
> > > >> the order in which they were executed.
> > > >
> > > > What does "order in which they were executed" mean with today's
> > > > multi-core and multi-execution unit CPUs?
> > > >
> > > > Thanks.
> > >
> > > "multi-core" doesn't enter into the picture here.
> > > The context is a single thread of control.
> > > And "multi-execution unit" doesn't either because
> > > that's just an underlying implementation detail
> > > of the CPU - the program must behave "as if"
> > > each instruction is executed serially
> > > (or as otherwise defined by the ISA).
> > 
> > You and I know that, but the text makes it sound as if each
> > instruction was somehow stamped with its execution time, and then the
> > instruction stream presented in that order, after annotating each
> > instruction with its source.  And that's misleading, IMO, because
> > evidently that's not what will happen.
> 
> It's not a per-instruction timestamp but it's h/w supported execution tracing.
> The h/w generates a trace of executed instructions (per h/w thread), the OS
> switches buffers to collect the trace per s/w thread, and GDB presents this to
> the user as execution-order disassembly (per thread).

So I suggest to tell that in the manual, and in general avoid saying
anything as definitive as "in the order they were executed", and
instead tell something like "in the order the hardware support for
execution tracing collects them".  This at least will point interested
readers to the vendor of the hardware if they want to ask specific
questions about the order.

Thanks.