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

[Eli Zaretskii <eliz at gnu dot org>]

> From: Doug Evans <dje@google.com>
> Date: Fri, 14 Aug 2015 10:06:15 -0700
> Cc: Markus Metzger <markus.t.metzger@intel.com>, Pedro Alves <palves@redhat.com>, 
> 	gdb-patches <gdb-patches@sourceware.org>
> 
> On Fri, Aug 14, 2015 at 6:45 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: Markus Metzger <markus.t.metzger@intel.com>
> >> Cc: gdb-patches@sourceware.org, dje@google.com
> >> Date: Fri, 14 Aug 2015 13:37:52 +0200
> >>
> >> 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.