[PATCH 2/2] btrace: set/show record btrace cpu
Eli Zaretskii
eliz@gnu.org
Thu Mar 1 14:48:00 GMT 2018
> 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.
More information about the Gdb-patches
mailing list