This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
RE: [rfc] btrace: change record instruction-history /m
- From: "Metzger, Markus T" <markus dot t dot metzger at intel dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: "dje at google dot com" <dje at google dot com>, "palves at redhat dot com" <palves at redhat dot com>, "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Tue, 18 Aug 2015 06:30:11 +0000
- Subject: RE: [rfc] btrace: change record instruction-history /m
- Authentication-results: sourceware.org; auth=none
- References: <1439552272-6256-1-git-send-email-markus dot t dot metzger at intel dot com> <83bneanfvb dot fsf at gnu dot org> <CADPb22S36oWzWagvHLHvc4aEnQCG1ddV5f1TbK6ddLY-DEHt2A at mail dot gmail dot com> <834mk1obll dot fsf at gnu dot org> <A78C989F6D9628469189715575E55B2333193E3D at IRSMSX104 dot ger dot corp dot intel dot com> <83a8tqlznh dot fsf at gnu dot org>
> -----Original Message-----
> From: Eli Zaretskii [mailto:eliz@gnu.org]
> Sent: Monday, August 17, 2015 5:10 PM
> To: Metzger, Markus T
> Cc: dje@google.com; palves@redhat.com; gdb-patches@sourceware.org
> Subject: Re: [rfc] btrace: change record instruction-history /m
>
> > 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.
How about "in the order they were recorded"?
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