[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