Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@imgtec.com>
To: Joel Sherrill <joel.sherrill@oarcorp.com>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: Help Translating Message from MIPS Simulator
Date: Sat, 15 Apr 2017 23:44:00 -0000	[thread overview]
Message-ID: <alpine.DEB.2.00.1704160008310.25796@tp.orcam.me.uk> (raw)
In-Reply-To: <1a3390f5-6456-d8bf-45b9-872c8be24a83@oarcorp.com>

On Sun, 16 Apr 2017, Joel Sherrill wrote:

> We have some RTEMS tests failing on the mips simulator
> in gdb. We are using the jmr3904 configuration and the
> run ends with this message:
> 
> HILO: MFHI: MF at 0x88015698 following OP at 0x88000464 corrupted by MT at
> 0x88003c68
> 
> 0x88000464 does appear to be in a reasonable location
> inside the test.
> 
> How do I translate the rest to get an idea about the fault?

 I'll give some background information.

 In MIPS architecture HILO or HI/LO is the integer multiply-divide (MD) 
unit's accumulator aka the HI and LO register pair.  For widening 
multiplication LO holds the low part of the product and HI holds the 
corresponding high part.  For division LO holds the quotient and HI holds 
the remainder.

 These registers are not a part of the general ALU and therefore special 
operations have been defined to retrieve and also to store data there:
MFHI and MFLO (Move From HI/LO) are the read instructions and MTHI and 
MTLO (Move To HI/LO) are the write instructions for the HI and the LO 
register respectively.

 In older architecture revisions the MTHI and MTLO instructions are only 
really useful for context switches as data placed there cannot be further 
used, except to read it back with MFHI or MFLO.  Consequently MTHI and 
MTLO are seldom used and those architecture revisions do not have hardware 
interlocks implemented for them, requiring a sufficient number of other 
instructions to be executed between a MFHI or MFLO and a following MTHI or 
MTLO for predictable results to be produced.  Otherwise the MTHI/MTLO 
operation may (and generally will) corrupt data retrieved with MFHI/MFLO.

 NB later architecture revisions have integer multiply-accumulate 
instructions which use HI/LO as one of inputs, making MTHI and MTLO more 
useful, and they do implement hardware interlocks for them.

 So the message above means that the result of a MFHI or MFLO operation 
(MF) at 0x88015698 executed after an MD unit operation (OP) at 0x88000464 
has been corrupted by a MTHI or MTLO operation (MT) at 0x88003c68.  And I 
believe that what I wrote above makes the HILO and MFHI prefixes obvious.

 HTH,

  Maciej


       reply	other threads:[~2017-04-15 23:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1a3390f5-6456-d8bf-45b9-872c8be24a83@oarcorp.com>
2017-04-15 23:44 ` Maciej W. Rozycki [this message]
2017-04-16 14:26   ` Joel Sherrill
2017-04-17 14:26     ` Joel Sherrill
2017-04-17 14:30     ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.00.1704160008310.25796@tp.orcam.me.uk \
    --to=macro@imgtec.com \
    --cc=gdb@sourceware.org \
    --cc=joel.sherrill@oarcorp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox