This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/2] btrace: set/show record btrace cpu
> 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.