Re: [PATCH 2/2] btrace: set/show record btrace cpu

[Eli Zaretskii <eliz@gnu.org>]

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