From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119436 invoked by alias); 17 Aug 2015 15:10:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 119423 invoked by uid 89); 17 Aug 2015 15:10:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout28.012.net.il Received: from mtaout28.012.net.il (HELO mtaout28.012.net.il) (80.179.55.184) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Aug 2015 15:10:09 +0000 Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NT800200FCR1A00@mtaout28.012.net.il> for gdb-patches@sourceware.org; Mon, 17 Aug 2015 18:10:04 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NT800G2BFGST2A0@mtaout28.012.net.il>; Mon, 17 Aug 2015 18:10:04 +0300 (IDT) Date: Mon, 17 Aug 2015 15:10:00 -0000 From: Eli Zaretskii Subject: Re: [rfc] btrace: change record instruction-history /m In-reply-to: To: "Metzger, Markus T" Cc: dje@google.com, palves@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83a8tqlznh.fsf@gnu.org> References: <1439552272-6256-1-git-send-email-markus.t.metzger@intel.com> <83bneanfvb.fsf@gnu.org> <834mk1obll.fsf@gnu.org> X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00426.txt.bz2 > From: "Metzger, Markus T" > CC: "palves@redhat.com" , "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.