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

Metzger, Markus T markus.t.metzger@intel.com
Mon Aug 17 07:16:00 GMT 2015


> -----Original Message-----
> From: Eli Zaretskii [mailto:eliz@gnu.org]
> Sent: Friday, August 14, 2015 10:32 PM
> To: Doug Evans
> Cc: Metzger, Markus T; palves@redhat.com; gdb-patches@sourceware.org
> Subject: Re: [rfc] btrace: change record instruction-history /m
> 
> > 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.

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).

Now we need to interleave sources into this stream of instructions.

Regards,
Markus.

Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Prof. Dr. Hermann Eul
Chairperson of the Supervisory Board: Tiffany Doon Silva
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928



More information about the Gdb-patches mailing list