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

Maciej W. Rozycki macro@mips.com
Fri Mar 2 14:50:00 GMT 2018


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



More information about the Gdb-patches mailing list