Message ID | A78C989F6D9628469189715575E55B236964DCE6@IRSMSX104.ger.corp.intel.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 113952 invoked by alias); 28 Feb 2018 07:38:10 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 113943 invoked by uid 89); 28 Feb 2018 07:38:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, SPF_PASS, T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mga06.intel.com Received: from mga06.intel.com (HELO mga06.intel.com) (134.134.136.31) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Feb 2018 07:38:08 +0000 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2018 23:38:05 -0800 X-ExtLoop1: 1 Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga004.jf.intel.com with ESMTP; 27 Feb 2018 23:38:04 -0800 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.101]) by IRSMSX108.ger.corp.intel.com ([169.254.11.9]) with mapi id 14.03.0319.002; Wed, 28 Feb 2018 07:38:03 +0000 From: "Metzger, Markus T" <markus.t.metzger@intel.com> To: Eli Zaretskii <eliz@gnu.org> CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> Subject: RE: [PATCH 2/2] btrace: set/show record btrace cpu Date: Wed, 28 Feb 2018 07:38:03 +0000 Message-ID: <A78C989F6D9628469189715575E55B236964DCE6@IRSMSX104.ger.corp.intel.com> References: <1519379570-16643-1-git-send-email-markus.t.metzger@intel.com> <1519379570-16643-2-git-send-email-markus.t.metzger@intel.com> <83woz34xuj.fsf@gnu.org> <A78C989F6D9628469189715575E55B236964BF9A@IRSMSX104.ger.corp.intel.com> <83lgff1s4n.fsf@gnu.org> <A78C989F6D9628469189715575E55B236964C68C@IRSMSX104.ger.corp.intel.com> <83y3jez3yw.fsf@gnu.org> In-Reply-To: <83y3jez3yw.fsf@gnu.org> x-ctpclassification: CTP_NT x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYzIwYmJjNTEtOTQwYi00ZDBmLTkwYjctMDBiNTU0ZWVlYzczIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjIuNS4xOCIsIlRydXN0ZWRMYWJlbEhhc2giOiJFNnU3ZzVPREdHSllcL0djdmQ4MnFhdTUxRXQ5ejZFb1ZobHFtUHB1U29aREhmXC9Od2VxR1pTeURyZnV0c1RkQnkifQ== dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes |
Commit Message
Metzger, Markus T
Feb. 28, 2018, 7:38 a.m. UTC
Hello Eli, > Thanks. Then I suggest to have this text in the manual: > > @item set record btrace cpu @var{identifier} > Set the processor to be used for enabling workarounds for processor > errata when decoding the trace. > > @cindex processor errata > @dfn{Processor errata} are bugs in processor firmware that can cause > a trace not to match the specification. Trace decoders that are > unaware of these errata might fail to decode such a trace. > @value{GDBN} can detect erroneous trace packets and correct them, > thus avoiding the decoding failures. These corrections are known as > @dfn{errata workarounds}, and are enabled based on the processor on > which the trace was recorded. I'm not sure whether the term 'firmware' is correct. I would instead phrase it like this: "Errata may cause the recorded trace to not match the specification. This, in turn, may cause trace decode to fail". Then continue with "@value{GDBN} can detect ..." as you suggested. > By default, @value{GDBN} attempts to detect the processor > automatically, and apply the necessary workarounds for it. However, > you may need to specify the processor if @value{GDBN} does not yet > support it. This command allows you to do that, and also allows to > disable the workarounds. That sounds good. Thanks for your help. Below is the full doc patch. 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, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
Comments
> From: "Metzger, Markus T" <markus.t.metzger@intel.com> > CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> > Date: Wed, 28 Feb 2018 07:38:03 +0000 > > > > @item set record btrace cpu @var{identifier} > > Set the processor to be used for enabling workarounds for processor > > errata when decoding the trace. > > > > @cindex processor errata > > @dfn{Processor errata} are bugs in processor firmware that can cause > > a trace not to match the specification. Trace decoders that are > > unaware of these errata might fail to decode such a trace. > > @value{GDBN} can detect erroneous trace packets and correct them, > > thus avoiding the decoding failures. These corrections are known as > > @dfn{errata workarounds}, and are enabled based on the processor on > > which the trace was recorded. > > I'm not sure whether the term 'firmware' is correct. I would instead phrase > it like this: > > "Errata may cause the recorded trace to not match the specification. This, > in turn, may cause trace decode to fail". But that completely loses the explanation of what the errata are. If my explanation is not accurate, let's correct it, rather than deleting it.
Hello Eli, > > > @cindex processor errata > > > @dfn{Processor errata} are bugs in processor firmware that can cause > > > a trace not to match the specification. Trace decoders that are > > > unaware of these errata might fail to decode such a trace. > > > @value{GDBN} can detect erroneous trace packets and correct them, > > > thus avoiding the decoding failures. These corrections are known as > > > @dfn{errata workarounds}, and are enabled based on the processor on > > > which the trace was recorded. > > > > I'm not sure whether the term 'firmware' is correct. I would instead > > phrase it like this: > > > > "Errata may cause the recorded trace to not match the specification. > > This, in turn, may cause trace decode to fail". > > But that completely loses the explanation of what the errata are. If my > explanation is not accurate, let's correct it, rather than deleting it. I didn't mean to delete your explanation. I only removed the 'firmware' part. And the bit about 'unaware decoders' because it really only matters to the reader what GDB's decoder does. Or that's what I thought I did. What else is missing? Thanks, 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, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
> From: "Metzger, Markus T" <markus.t.metzger@intel.com> > CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> > Date: Thu, 1 Mar 2018 07:05:42 +0000 > > > > > @cindex processor errata > > > > @dfn{Processor errata} are bugs in processor firmware that can cause > > > > a trace not to match the specification. Trace decoders that are > > > > unaware of these errata might fail to decode such a trace. > > > > @value{GDBN} can detect erroneous trace packets and correct them, > > > > thus avoiding the decoding failures. These corrections are known as > > > > @dfn{errata workarounds}, and are enabled based on the processor on > > > > which the trace was recorded. > > > > > But that completely loses the explanation of what the errata are. If my > > explanation is not accurate, let's correct it, rather than deleting it. > > I didn't mean to delete your explanation. I only removed the 'firmware' part. The text I proposed is above. It begins with an explanation of what those errata are, and why they are detrimental to btrace. The text you proposed instead is this: Errata may cause the recorded trace to not match the specification. This, in turn, may cause trace decode to fail. @value{GDBN} can detect erroneous trace packets and correct them, thus avoiding the decoding failures. These corrections are known as @dfn{errata workarounds}, and are enabled based on the processor on which the trace was recorded. This just says that trace decode can fail, but tells nothing about the phenomenon itself. Thus my "completely loses" reaction. But I don't want to argue. If you feel that the text you wrote is good enough, go ahead and push it, even though I'm unhappy. Thanks.
Hello Eli, > > > > > @cindex processor errata > > > > > @dfn{Processor errata} are bugs in processor firmware that can cause > > > > > a trace not to match the specification. Trace decoders that are > > > > > unaware of these errata might fail to decode such a trace. > > > > > @value{GDBN} can detect erroneous trace packets and correct them, > > > > > thus avoiding the decoding failures. These corrections are known as > > > > > @dfn{errata workarounds}, and are enabled based on the processor on > > > > > which the trace was recorded. > > > > > > > But that completely loses the explanation of what the errata are. > > > If my explanation is not accurate, let's correct it, rather than deleting it. > > > > I didn't mean to delete your explanation. I only removed the 'firmware' part. > > The text I proposed is above. It begins with an explanation of what those errata > are, and why they are detrimental to btrace. The text you proposed instead is > this: > > Errata may cause the recorded trace to not match the specification. > This, in turn, may cause trace decode to fail. @value{GDBN} can > detect erroneous trace packets and correct them, thus avoiding the > decoding failures. These corrections are known as @dfn{errata > workarounds}, and are enabled based on the processor on which the > trace was recorded. > > This just says that trace decode can fail, but tells nothing about the phenomenon > itself. Thus my "completely loses" reaction. > > But I don't want to argue. If you feel that the text you wrote is good enough, go > ahead and push it, even though I'm unhappy. I'd rather we find a wording we can all agree on. I added that errata cause the trace to not match the spec and that this would cause decode to fail. I removed the bit about errata being in the firmware since that is not correct. And I replaced "unaware decoders might fail to decode such a trace" with "This, in turn, may cause trace decode to fail". The rest I took as you suggested. Where do you think we need to improve the wording? Thanks, 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, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
> From: "Metzger, Markus T" <markus.t.metzger@intel.com> > CC: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> > Date: Thu, 1 Mar 2018 16:23:59 +0000 > > Where do you think we need to improve the wording? I'd like to have an explanation of what the errata are and what causes them. If "bugs in firmware" is inaccurate, then how do we describe the reason accurately? (If you can point me to some URL where that is described, I might be able to come up with an accurate description myself.) Than ks.
Hello Eli, > > Where do you think we need to improve the wording? > > I'd like to have an explanation of what the errata are and what causes them. If > "bugs in firmware" is inaccurate, then how do we describe the reason accurately? > (If you can point me to some URL where that is described, I might be able to > come up with an accurate description > myself.) The term "erratum" already means 'bug somewhere in the processor'. From https://en.wikipedia.org/wiki/Erratum: "Design errors and mistakes in a CPU's hardwired logic may also be documented and described as errata." Intel publishes them in documents called ....-spec-update.pdf. Thanks, 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, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
On Thu, 1 Mar 2018, Metzger, Markus T wrote:
> The term "erratum" already means 'bug somewhere in the processor'.
The term "erratum" is generic and usually means a mistake in a published
text. You need to be more specific and clarify what the term means in
this context.
I think that Eli's proposal sounds about right, except that I agree that
"firmware" does not really fit here; an erratum may be present in hardware
logic or in microcode, or it may even be a phenomenon of the manufacturing
process, e.g. cases have been known where a malfunction of a specific CPU
operation was caused by thermal effects in silicon in otherwise seemingly
correct logic. This makes a "processor erratum" a broad term and
therefore I think this specific case does not belong to the concept index.
So how about:
Processor errata are known to exist that can cause a trace not to match
the specification. Trace decoders that are unaware of these errata
might fail to decode such a trace. @value{GDBN} can detect erroneous
trace packets and correct them, thus avoiding the decoding failures.
These corrections or workarounds are enabled based on the processor on
which the trace was recorded.
?
Maciej
> Date: Fri, 2 Mar 2018 14:15:20 +0000 > From: "Maciej W. Rozycki" <macro@mips.com> > CC: Eli Zaretskii <eliz@gnu.org>, "gdb-patches@sourceware.org" > <gdb-patches@sourceware.org> > > On Thu, 1 Mar 2018, Metzger, Markus T wrote: > > > The term "erratum" already means 'bug somewhere in the processor'. > > The term "erratum" is generic and usually means a mistake in a published > text. You need to be more specific and clarify what the term means in > this context. > > I think that Eli's proposal sounds about right, except that I agree that > "firmware" does not really fit here; an erratum may be present in hardware > logic or in microcode, or it may even be a phenomenon of the manufacturing > process, e.g. cases have been known where a malfunction of a specific CPU > operation was caused by thermal effects in silicon in otherwise seemingly > correct logic. This makes a "processor erratum" a broad term and > therefore I think this specific case does not belong to the concept index. > > So how about: > > Processor errata are known to exist that can cause a trace not to match > the specification. Trace decoders that are unaware of these errata > might fail to decode such a trace. @value{GDBN} can detect erroneous > trace packets and correct them, thus avoiding the decoding failures. > These corrections or workarounds are enabled based on the processor on > which the trace was recorded. That still doesn't explain what are those errata. How about replacing the first sentence above with these two: Processor errata are defects in processor operation, caused by its design or manufacture. They can cause a trace not to match the specification.
On Fri, 2 Mar 2018, Eli Zaretskii wrote: > > So how about: > > > > Processor errata are known to exist that can cause a trace not to match > > the specification. Trace decoders that are unaware of these errata > > might fail to decode such a trace. @value{GDBN} can detect erroneous > > trace packets and correct them, thus avoiding the decoding failures. > > These corrections or workarounds are enabled based on the processor on > > which the trace was recorded. > > That still doesn't explain what are those errata. > > How about replacing the first sentence above with these two: > > Processor errata are defects in processor operation, caused by its > design or manufacture. They can cause a trace not to match the > specification. Fine with me. Maciej
On Fri, 2 Mar 2018, Eli Zaretskii wrote: > > So how about: > > > > Processor errata are known to exist that can cause a trace not to match > > the specification. Trace decoders that are unaware of these errata > > might fail to decode such a trace. @value{GDBN} can detect erroneous > > trace packets and correct them, thus avoiding the decoding failures. > > These corrections or workarounds are enabled based on the processor on > > which the trace was recorded. > > That still doesn't explain what are those errata. > > How about replacing the first sentence above with these two: > > Processor errata are defects in processor operation, caused by its > design or manufacture. They can cause a trace not to match the > specification. Fine with me. Maciej
Hello Eli, Maciej, > > > So how about: > > > > > > Processor errata are known to exist that can cause a trace not to match > > > the specification. Trace decoders that are unaware of these errata > > > might fail to decode such a trace. @value{GDBN} can detect erroneous > > > trace packets and correct them, thus avoiding the decoding failures. > > > These corrections or workarounds are enabled based on the processor on > > > which the trace was recorded. > > > > That still doesn't explain what are those errata. > > > > How about replacing the first sentence above with these two: > > > > Processor errata are defects in processor operation, caused by its > > design or manufacture. They can cause a trace not to match the > > specification. > > Fine with me. Fine with me, as well. I will send out the full series with the updated wording and a reduced column limit. Thanks, 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, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index ee7adc8..2abb8d7 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -6952,10 +6952,72 @@ and to read-write memory. Beware that the accessed memory corresponds to the live target and not necessarily to the current replay position. +@item set record btrace cpu @var{identifier} +Set the processor to be used for enabling workarounds for processor +errata when decoding the trace. + +Errata may cause the recorded trace to not match the specification. +This, in turn, may cause trace decode to fail. @value{GDBN} can +detect erroneous trace packets and correct them, thus avoiding the +decoding failures. These corrections are known as @dfn{errata +workarounds}, and are enabled based on the processor on which the +trace was recorded. + +By default, @value{GDBN} attempts to detect the processor +automatically, and apply the necessary workarounds for it. However, +you may need to specify the processor if @value{GDBN} does not yet +support it. This command allows you to do that, and also allows to +disable the workarounds. + +The argument @var{identifier} identifies the @sc{cpu} and is of the +form: @code{@var{vendor}:@var{procesor identifier}}. In addition, +there are two special identifiers, @code{none} and @code{auto} +(default). + +The following vendor identifiers and corresponding processor +identifiers are currently supported: + +@multitable @columnfractions .1 .9 + +@item @code{intel} +@tab @var{family}/@var{model}[/@var{stepping}] + +@end multitable + +On GNU/Linux systems, the processor @var{family}, @var{model}, and +@var{stepping} can be obtained from @code{/proc/cpuinfo}. + +If @var{identifier} is @code{auto}, enable errata workarounds for the +processor on which the trace was recorded. If @var{identifier} is +@code{none}, errata workarounds are disabled. + +For example, when using an old @value{GDBN} on a new system, decode +may fail because @value{GDBN} does not support the new processor. It +often suffices to specify an older processor that @value{GDBN} +supports. + +@smallexample +(gdb) info record +Active record target: record-btrace +Recording format: Intel Processor Trace. +Buffer size: 16kB. +Failed to configure the Intel Processor Trace decoder: unknown cpu. +(gdb) set record btrace cpu intel:6/158 +(gdb) info record +Active record target: record-btrace +Recording format: Intel Processor Trace. +Buffer size: 16kB. +Recorded 84872 instructions in 3189 functions (0 gaps) for thread 1 (...). +@end smallexample + @kindex show record btrace @item show record btrace replay-memory-access Show the current setting of @code{replay-memory-access}. +@item show record btrace cpu +Show the processor to be used for enabling trace decode errata +workarounds. + @kindex set record btrace bts @item set record btrace bts buffer-size @var{size} @itemx set record btrace bts buffer-size unlimited