[RFC PATCH-for-5.0?] target/mips/translate: Report exception in delay slot as UNPREDICTABLE

[RFC PATCH-for-5.0?] target/mips/translate: Report exception in delay slot as UNPREDICTABLE

[Philippe Mathieu-Daudé]

Using the BC1ANY4F instruction with a 24Kf core (MIPS32R2
& ASE_MIPS16) we get:

  $ echo -ne '\x03\x20\xf8\x09EEEE' > cop1x.bin
  $ qemu-system-mipsel -bios cop1x.bin
  unknown branch 0x13000
  Aborted (core dumped)

  (gdb) bt
  #0  0x00007fe2d38b1e35 in raise () at /lib64/libc.so.6
  #1  0x00007fe2d389c895 in abort () at /lib64/libc.so.6
  #2  0x000055aa9fe066e5 in gen_branch (ctx=0x7fe27bdfa590, insn_bytes=4) at target/mips/translate.c:13167
  #3  0x000055aa9fe2baf4 in mips_tr_translate_insn (dcbase=0x7fe27bdfa590, cs=0x55aaa0e2d530) at target/mips/translate.c:30928
  #4  0x000055aa9fd40138 in translator_loop (ops=0x55aaa05e94e0 <mips_tr_ops>, db=0x7fe27bdfa590, cpu=0x55aaa0e2d530, tb=0x7fe284000040 <code_gen_buffer+19>, max_insns=512) at accel/tcg/translator.c:102
  #5  0x000055aa9fe2bd21 in gen_intermediate_code (cs=0x55aaa0e2d530, tb=0x7fe284000040 <code_gen_buffer+19>, max_insns=512) at target/mips/translate.c:30999
  #6  0x000055aa9fd3e3d4 in tb_gen_code (cpu=0x55aaa0e2d530, pc=3217031168, cs_base=0, flags=268435600, cflags=-16252928) at accel/tcg/translate-all.c:1718
  #7  0x000055aa9fd3ac06 in tb_find (cpu=0x55aaa0e2d530, last_tb=0x0, tb_exit=0, cf_mask=524288) at accel/tcg/cpu-exec.c:407
  #8  0x000055aa9fd3b4d5 in cpu_exec (cpu=0x55aaa0e2d530) at accel/tcg/cpu-exec.c:731
  #9  0x000055aa9fcfe33a in tcg_cpu_exec (cpu=0x55aaa0e2d530) at cpus.c:1405
  #10 0x000055aa9fcfeb90 in qemu_tcg_cpu_thread_fn (arg=0x55aaa0e2d530) at cpus.c:1713
  #11 0x000055aaa02ea7d7 in qemu_thread_start (args=0x55aaa0e465f0) at util/qemu-thread-posix.c:519
  #12 0x00007fe2d3a484c0 in start_thread () at /lib64/libpthread.so.0
  #13 0x00007fe2d3976163 in clone () at /lib64/libc.so.6

This is because this COP1X instruction generates a Reserved
Instruction when used with this core, however we are in a delay
slot, and exceptions in delay slot are architecturally unpredictable.

Core dumps confunse users. Instead, report a friendlier error message:

  $ qemu-system-mipsel -bios cop1x.bin
  qemu-system-mipsel: Exception in delay slot is UNPREDICTABLE

Buglink: https://bugs.launchpad.net/qemu/+bug/1663287
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 target/mips/translate.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index 25b595a17d..99e675b87a 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -30925,6 +30925,10 @@ static void mips_tr_translate_insn(DisasContextBase *dcbase, CPUState *cs)
         }
     }
     if (is_slot) {
+        if (ctx->base.is_jmp == DISAS_NORETURN) {
+            error_report("Exception in delay slot is UNPREDICTABLE");
+            exit(1);
+        }
         gen_branch(ctx, insn_bytes);
     }
     ctx->base.pc_next += insn_bytes;
-- 
2.21.1

Re: [RFC PATCH-for-5.0?] target/mips/translate: Report exception in delay slot as UNPREDICTABLE

[Philippe Mathieu-Daudé]

On 4/7/20 1:54 AM, Philippe Mathieu-Daudé wrote:
> Using the BC1ANY4F instruction with a 24Kf core (MIPS32R2
> & ASE_MIPS16) we get:
> 
>    $ echo -ne '\x03\x20\xf8\x09EEEE' > cop1x.bin
>    $ qemu-system-mipsel -bios cop1x.bin
>    unknown branch 0x13000
>    Aborted (core dumped)
> 
>    (gdb) bt
>    #0  0x00007fe2d38b1e35 in raise () at /lib64/libc.so.6
>    #1  0x00007fe2d389c895 in abort () at /lib64/libc.so.6
>    #2  0x000055aa9fe066e5 in gen_branch (ctx=0x7fe27bdfa590, insn_bytes=4) at target/mips/translate.c:13167
>    #3  0x000055aa9fe2baf4 in mips_tr_translate_insn (dcbase=0x7fe27bdfa590, cs=0x55aaa0e2d530) at target/mips/translate.c:30928
>    #4  0x000055aa9fd40138 in translator_loop (ops=0x55aaa05e94e0 <mips_tr_ops>, db=0x7fe27bdfa590, cpu=0x55aaa0e2d530, tb=0x7fe284000040 <code_gen_buffer+19>, max_insns=512) at accel/tcg/translator.c:102
>    #5  0x000055aa9fe2bd21 in gen_intermediate_code (cs=0x55aaa0e2d530, tb=0x7fe284000040 <code_gen_buffer+19>, max_insns=512) at target/mips/translate.c:30999
>    #6  0x000055aa9fd3e3d4 in tb_gen_code (cpu=0x55aaa0e2d530, pc=3217031168, cs_base=0, flags=268435600, cflags=-16252928) at accel/tcg/translate-all.c:1718
>    #7  0x000055aa9fd3ac06 in tb_find (cpu=0x55aaa0e2d530, last_tb=0x0, tb_exit=0, cf_mask=524288) at accel/tcg/cpu-exec.c:407
>    #8  0x000055aa9fd3b4d5 in cpu_exec (cpu=0x55aaa0e2d530) at accel/tcg/cpu-exec.c:731
>    #9  0x000055aa9fcfe33a in tcg_cpu_exec (cpu=0x55aaa0e2d530) at cpus.c:1405
>    #10 0x000055aa9fcfeb90 in qemu_tcg_cpu_thread_fn (arg=0x55aaa0e2d530) at cpus.c:1713
>    #11 0x000055aaa02ea7d7 in qemu_thread_start (args=0x55aaa0e465f0) at util/qemu-thread-posix.c:519
>    #12 0x00007fe2d3a484c0 in start_thread () at /lib64/libpthread.so.0
>    #13 0x00007fe2d3976163 in clone () at /lib64/libc.so.6
> 
> This is because this COP1X instruction generates a Reserved
> Instruction when used with this core, however we are in a delay
> slot, and exceptions in delay slot are architecturally unpredictable.
> 
> Core dumps confunse users. Instead, report a friendlier error message:
> 
>    $ qemu-system-mipsel -bios cop1x.bin
>    qemu-system-mipsel: Exception in delay slot is UNPREDICTABLE
> 
> Buglink: https://bugs.launchpad.net/qemu/+bug/1663287
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>   target/mips/translate.c | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/target/mips/translate.c b/target/mips/translate.c
> index 25b595a17d..99e675b87a 100644
> --- a/target/mips/translate.c
> +++ b/target/mips/translate.c
> @@ -30925,6 +30925,10 @@ static void mips_tr_translate_insn(DisasContextBase *dcbase, CPUState *cs)
>           }
>       }
>       if (is_slot) {
> +        if (ctx->base.is_jmp == DISAS_NORETURN) {
> +            error_report("Exception in delay slot is UNPREDICTABLE");

"Exception/branch" actually.

> +            exit(1);
> +        }
>           gen_branch(ctx, insn_bytes);
>       }
>       ctx->base.pc_next += insn_bytes;
> 

Re: [RFC PATCH-for-5.0?] target/mips/translate: Report exception in delay slot as UNPREDICTABLE

[Peter Maydell]

On Tue, 7 Apr 2020 at 00:55, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> Using the BC1ANY4F instruction with a 24Kf core (MIPS32R2
> & ASE_MIPS16) we get:
>
>   $ echo -ne '\x03\x20\xf8\x09EEEE' > cop1x.bin
>   $ qemu-system-mipsel -bios cop1x.bin
>   unknown branch 0x13000
>   Aborted (core dumped)

> This is because this COP1X instruction generates a Reserved
> Instruction when used with this core, however we are in a delay
> slot, and exceptions in delay slot are architecturally unpredictable.
>
> Core dumps confunse users. Instead, report a friendlier error message:
>
>   $ qemu-system-mipsel -bios cop1x.bin
>   qemu-system-mipsel: Exception in delay slot is UNPREDICTABLE

UNPREDICTABLE behaviour should not in QEMU include
causing QEMU to exit. You can log it with LOG_GUEST_ERROR
if you like but you should do something plausible (ideally what
some bit of real hardware does when this situation happens).

PS: does MIPS use the "UNPREDICTABLE" terminology? I
thought it was an Arm-ism, but maybe it's caught on more widely.

thanks
-- PMM

Re: [RFC PATCH-for-5.0?] target/mips/translate: Report exception in delay slot as UNPREDICTABLE

[Philippe Mathieu-Daudé]

On 4/7/20 10:35 AM, Peter Maydell wrote:
> On Tue, 7 Apr 2020 at 00:55, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> Using the BC1ANY4F instruction with a 24Kf core (MIPS32R2
>> & ASE_MIPS16) we get:
>>
>>    $ echo -ne '\x03\x20\xf8\x09EEEE' > cop1x.bin
>>    $ qemu-system-mipsel -bios cop1x.bin
>>    unknown branch 0x13000
>>    Aborted (core dumped)
> 
>> This is because this COP1X instruction generates a Reserved
>> Instruction when used with this core, however we are in a delay
>> slot, and exceptions in delay slot are architecturally unpredictable.
>>
>> Core dumps confunse users. Instead, report a friendlier error message:
>>
>>    $ qemu-system-mipsel -bios cop1x.bin
>>    qemu-system-mipsel: Exception in delay slot is UNPREDICTABLE
> 
> UNPREDICTABLE behaviour should not in QEMU include
> causing QEMU to exit. You can log it with LOG_GUEST_ERROR
> if you like but you should do something plausible (ideally what
> some bit of real hardware does when this situation happens).

OK. I have no clue how real 24Kf deals with it - I don't own one -, it 
is not in my list of interests (and my list of interests - which I can 
reproduce - is not modeled in QEMU).

> 
> PS: does MIPS use the "UNPREDICTABLE" terminology? I
> thought it was an Arm-ism, but maybe it's caught on more widely.

At least it appears in my MIPS32 ISA Vol II (Revision 0.95) copy from 2001:

1.2  UNPREDICTABLE and UNDEFINED

1.2.1  UNPREDICTABLE
UNPREDICTABLE results may vary from processor implementation to 
implementation, instruction to instruction, oras a function of time on 
the same implementation or instruction. Software can never depend on 
results that are UNPREDICTABLE. UNPREDICTABLE operations may cause a 
result to be generated or not. If a result is generated,it is 
UNPREDICTABLE. UNPREDICTABLE operations may cause arbitrary exceptions.
UNPREDICTABLE results or operations have several implementation 
restrictions:
• Implementations of operations generating UNPREDICTABLE results must 
not depend on any data source (memory or internal state) which is 
inaccessible in the current processor mode
• UNPREDICTABLE operations must not read, write, or modify the contents 
of memory or internal state which is inaccessible in the current 
processor mode. For example, UNPREDICTABLE operations executed in user 
mode must not access memory or internal state that is only accessible in 
Kernel Mode or Debug Mode or in another process
• UNPREDICTABLE operations must not halt or hang the processor

1.2.2  UNDEFINED
UNDEFINED operations or behavior may vary from processor implementation 
to implementation, instruction to instruction, or as a function of time 
on the same implementation or instruction. UNDEFINED operations or 
behavior may vary from nothing to creating an environment in which 
execution can no longer continue. UNDEFINED operations or behavior may 
cause data loss.
UNDEFINED operations or behavior has one implementation restriction:
• UNDEFINED operations or behavior must not cause the processor to hang 
(that is, enter a state from which there is no exit other than powering 
down the processor). The assertion of any of the reset signals must 
restore the processorto an operational state

Then:

Jump and Link Register (JALR)

Processor operation is UNPREDICTABLE if a branch, jump, ERET, DERET, or 
WAIT instruction is placed in the delay slot of a branch or jump.

---

On Vol I Rev 6.01:

5.3.2.1  Control Transfer Instructions in Delay Slots and Forbidden Slots

In MIPS architectures prior to Release 6. if a control transfer 
instruction (CTI) is placed in a branch delay slot, the operation of 
both instructions is UNPREDICTABLE. In Release 6, if a CTI is placed in 
a branch delay slot or a compact branch forbidden slot, implementations 
are required to signal a Reserved Instruction exception.

The following instructions are forbidden in branch delay slots and 
forbidden slots: any CTI, including branches and jumps, ERET, ERETNC, 
DERET, WAIT, and PAUSE. Their occurrence is required to signal a 
Reserved Instruction exception.

5.3.2.2  Exceptions and Delay and Forbidden Slots

If an exception or interrupt prevents the completion of an instruction 
in a delay slot or forbidden slot, the hardware reports an Exception PC 
(CP0 EPC) of the branch, with a status bit set (StatusBD) to indicate 
that the exception was for the instruction in the delay slot of the branch.
By convention, if an exception or interrupt prevents the completion of 
an instruction in a branch delay or forbidden slot, the branch 
instruction is re-executed and branch instructions must be restartable 
to permit this. In particular, procedure calls must be restartable. To 
insure that a procedure call is restartable, procedure calls that have a 
delay slot or forbidden slot (branch/jump-and-link instructions) should 
not use the register in which the return link is stored (usu-ally GPR 
31) as a source register. This applies to all branch/jump-and-link 
instructions that have both a slot (delay or forbidden) and source 
registers, both for conditions (e.g., BGEZAL or BGEZALC) or for jump 
targets (JALR).

---

I would have expected the behavior match the UNDEFINED description, as 
Yongbok Kim commented here:
https://bugs.launchpad.net/qemu/+bug/1663287/comments/3

   branches in a delay slot is "undefined" in the pre-Release
   6 architecture. MIPS architectre release 6 defines to signal
   Reserved Instruction exceptions for such cases.

But it really appears as UNPREDICTABLE.

Re: [RFC PATCH-for-5.0?] target/mips/translate: Report exception in delay slot as UNPREDICTABLE

[Philippe Mathieu-Daudé]

On 4/7/20 11:23 AM, Philippe Mathieu-Daudé wrote:
> On 4/7/20 10:35 AM, Peter Maydell wrote:
>> On Tue, 7 Apr 2020 at 00:55, Philippe Mathieu-Daudé <f4bug@amsat.org> 
>> wrote:
>>>
>>> Using the BC1ANY4F instruction with a 24Kf core (MIPS32R2
>>> & ASE_MIPS16) we get:
>>>
>>>    $ echo -ne '\x03\x20\xf8\x09EEEE' > cop1x.bin
>>>    $ qemu-system-mipsel -bios cop1x.bin
>>>    unknown branch 0x13000
>>>    Aborted (core dumped)
>>
>>> This is because this COP1X instruction generates a Reserved
>>> Instruction when used with this core, however we are in a delay
>>> slot, and exceptions in delay slot are architecturally unpredictable.
>>>
>>> Core dumps confunse users. Instead, report a friendlier error message:
>>>
>>>    $ qemu-system-mipsel -bios cop1x.bin
>>>    qemu-system-mipsel: Exception in delay slot is UNPREDICTABLE
>>
>> UNPREDICTABLE behaviour should not in QEMU include
>> causing QEMU to exit. You can log it with LOG_GUEST_ERROR
>> if you like but you should do something plausible (ideally what
>> some bit of real hardware does when this situation happens).
> 
> OK. I have no clue how real 24Kf deals with it - I don't own one -, it 
> is not in my list of interests (and my list of interests - which I can 
> reproduce - is not modeled in QEMU).
> 
>>
>> PS: does MIPS use the "UNPREDICTABLE" terminology? I
>> thought it was an Arm-ism, but maybe it's caught on more widely.
> 
> At least it appears in my MIPS32 ISA Vol II (Revision 0.95) copy from 2001:
> 
> 1.2  UNPREDICTABLE and UNDEFINED
> 
> 1.2.1  UNPREDICTABLE
> UNPREDICTABLE results may vary from processor implementation to 
> implementation, instruction to instruction, oras a function of time on 
> the same implementation or instruction. Software can never depend on 
> results that are UNPREDICTABLE. UNPREDICTABLE operations may cause a 
> result to be generated or not. If a result is generated,it is 
> UNPREDICTABLE. UNPREDICTABLE operations may cause arbitrary exceptions.
> UNPREDICTABLE results or operations have several implementation 
> restrictions:
> • Implementations of operations generating UNPREDICTABLE results must 
> not depend on any data source (memory or internal state) which is 
> inaccessible in the current processor mode
> • UNPREDICTABLE operations must not read, write, or modify the contents 
> of memory or internal state which is inaccessible in the current 
> processor mode. For example, UNPREDICTABLE operations executed in user 
> mode must not access memory or internal state that is only accessible in 
> Kernel Mode or Debug Mode or in another process
> • UNPREDICTABLE operations must not halt or hang the processor
> 
> 1.2.2  UNDEFINED
> UNDEFINED operations or behavior may vary from processor implementation 
> to implementation, instruction to instruction, or as a function of time 
> on the same implementation or instruction. UNDEFINED operations or 
> behavior may vary from nothing to creating an environment in which 
> execution can no longer continue. UNDEFINED operations or behavior may 
> cause data loss.
> UNDEFINED operations or behavior has one implementation restriction:
> • UNDEFINED operations or behavior must not cause the processor to hang 
> (that is, enter a state from which there is no exit other than powering 
> down the processor). The assertion of any of the reset signals must 
> restore the processorto an operational state
> 
> Then:
> 
> Jump and Link Register (JALR)
> 
> Processor operation is UNPREDICTABLE if a branch, jump, ERET, DERET, or 
> WAIT instruction is placed in the delay slot of a branch or jump.
> 
> ---
> 
> On Vol I Rev 6.01:
> 
> 5.3.2.1  Control Transfer Instructions in Delay Slots and Forbidden Slots
> 
> In MIPS architectures prior to Release 6. if a control transfer 
> instruction (CTI) is placed in a branch delay slot, the operation of 
> both instructions is UNPREDICTABLE. In Release 6, if a CTI is placed in 
> a branch delay slot or a compact branch forbidden slot, implementations 
> are required to signal a Reserved Instruction exception.

Which also means this patch is incorrect for CPUs implementing the 
Release 6 (which I'm not familiar with).

> 
> The following instructions are forbidden in branch delay slots and 
> forbidden slots: any CTI, including branches and jumps, ERET, ERETNC, 
> DERET, WAIT, and PAUSE. Their occurrence is required to signal a 
> Reserved Instruction exception.
> 
> 5.3.2.2  Exceptions and Delay and Forbidden Slots
> 
> If an exception or interrupt prevents the completion of an instruction 
> in a delay slot or forbidden slot, the hardware reports an Exception PC 
> (CP0 EPC) of the branch, with a status bit set (StatusBD) to indicate 
> that the exception was for the instruction in the delay slot of the branch.
> By convention, if an exception or interrupt prevents the completion of 
> an instruction in a branch delay or forbidden slot, the branch 
> instruction is re-executed and branch instructions must be restartable 
> to permit this. In particular, procedure calls must be restartable. To 
> insure that a procedure call is restartable, procedure calls that have a 
> delay slot or forbidden slot (branch/jump-and-link instructions) should 
> not use the register in which the return link is stored (usu-ally GPR 
> 31) as a source register. This applies to all branch/jump-and-link 
> instructions that have both a slot (delay or forbidden) and source 
> registers, both for conditions (e.g., BGEZAL or BGEZALC) or for jump 
> targets (JALR).
> 
> ---
> 
> I would have expected the behavior match the UNDEFINED description, as 
> Yongbok Kim commented here:
> https://bugs.launchpad.net/qemu/+bug/1663287/comments/3
> 
>    branches in a delay slot is "undefined" in the pre-Release
>    6 architecture. MIPS architectre release 6 defines to signal
>    Reserved Instruction exceptions for such cases.
> 
> But it really appears as UNPREDICTABLE.

Re: [RFC PATCH-for-5.0?] target/mips/translate: Report exception in delay slot as UNPREDICTABLE

[Aleksandar Markovic]

[-- Attachment #1: Type: text/plain, Size: 6593 bytes --]

11:32 Uto, 07.04.2020. Philippe Mathieu-Daudé <philmd@redhat.com> је
написао/ла:
>
> On 4/7/20 11:23 AM, Philippe Mathieu-Daudé wrote:
> > On 4/7/20 10:35 AM, Peter Maydell wrote:
> >> On Tue, 7 Apr 2020 at 00:55, Philippe Mathieu-Daudé <f4bug@amsat.org>
> >> wrote:
> >>>
> >>> Using the BC1ANY4F instruction with a 24Kf core (MIPS32R2
> >>> & ASE_MIPS16) we get:
> >>>
> >>>    $ echo -ne '\x03\x20\xf8\x09EEEE' > cop1x.bin
> >>>    $ qemu-system-mipsel -bios cop1x.bin
> >>>    unknown branch 0x13000
> >>>    Aborted (core dumped)
> >>
> >>> This is because this COP1X instruction generates a Reserved
> >>> Instruction when used with this core, however we are in a delay
> >>> slot, and exceptions in delay slot are architecturally unpredictable.
> >>>
> >>> Core dumps confunse users. Instead, report a friendlier error message:
> >>>
> >>>    $ qemu-system-mipsel -bios cop1x.bin
> >>>    qemu-system-mipsel: Exception in delay slot is UNPREDICTABLE
> >>
> >> UNPREDICTABLE behaviour should not in QEMU include
> >> causing QEMU to exit. You can log it with LOG_GUEST_ERROR
> >> if you like but you should do something plausible (ideally what
> >> some bit of real hardware does when this situation happens).
> >
> > OK. I have no clue how real 24Kf deals with it - I don't own one -, it
> > is not in my list of interests (and my list of interests - which I can
> > reproduce - is not modeled in QEMU).
> >
> >>
> >> PS: does MIPS use the "UNPREDICTABLE" terminology? I
> >> thought it was an Arm-ism, but maybe it's caught on more widely.
> >
> > At least it appears in my MIPS32 ISA Vol II (Revision 0.95) copy from
2001:
> >
> > 1.2  UNPREDICTABLE and UNDEFINED
> >
> > 1.2.1  UNPREDICTABLE
> > UNPREDICTABLE results may vary from processor implementation to
> > implementation, instruction to instruction, oras a function of time on
> > the same implementation or instruction. Software can never depend on
> > results that are UNPREDICTABLE. UNPREDICTABLE operations may cause a
> > result to be generated or not. If a result is generated,it is
> > UNPREDICTABLE. UNPREDICTABLE operations may cause arbitrary exceptions.
> > UNPREDICTABLE results or operations have several implementation
> > restrictions:
> > • Implementations of operations generating UNPREDICTABLE results must
> > not depend on any data source (memory or internal state) which is
> > inaccessible in the current processor mode
> > • UNPREDICTABLE operations must not read, write, or modify the contents
> > of memory or internal state which is inaccessible in the current
> > processor mode. For example, UNPREDICTABLE operations executed in user
> > mode must not access memory or internal state that is only accessible
in
> > Kernel Mode or Debug Mode or in another process
> > • UNPREDICTABLE operations must not halt or hang the processor
> >
> > 1.2.2  UNDEFINED
> > UNDEFINED operations or behavior may vary from processor implementation
> > to implementation, instruction to instruction, or as a function of time
> > on the same implementation or instruction. UNDEFINED operations or
> > behavior may vary from nothing to creating an environment in which
> > execution can no longer continue. UNDEFINED operations or behavior may
> > cause data loss.
> > UNDEFINED operations or behavior has one implementation restriction:
> > • UNDEFINED operations or behavior must not cause the processor to hang
> > (that is, enter a state from which there is no exit other than powering
> > down the processor). The assertion of any of the reset signals must
> > restore the processorto an operational state
> >
> > Then:
> >
> > Jump and Link Register (JALR)
> >
> > Processor operation is UNPREDICTABLE if a branch, jump, ERET, DERET, or
> > WAIT instruction is placed in the delay slot of a branch or jump.
> >
> > ---
> >
> > On Vol I Rev 6.01:
> >
> > 5.3.2.1  Control Transfer Instructions in Delay Slots and Forbidden
Slots
> >
> > In MIPS architectures prior to Release 6. if a control transfer
> > instruction (CTI) is placed in a branch delay slot, the operation of
> > both instructions is UNPREDICTABLE. In Release 6, if a CTI is placed in
> > a branch delay slot or a compact branch forbidden slot, implementations
> > are required to signal a Reserved Instruction exception.
>
> Which also means this patch is incorrect for CPUs implementing the
> Release 6 (which I'm not familiar with).
>
> >
> > The following instructions are forbidden in branch delay slots and
> > forbidden slots: any CTI, including branches and jumps, ERET, ERETNC,
> > DERET, WAIT, and PAUSE. Their occurrence is required to signal a
> > Reserved Instruction exception.
> >
> > 5.3.2.2  Exceptions and Delay and Forbidden Slots
> >
> > If an exception or interrupt prevents the completion of an instruction
> > in a delay slot or forbidden slot, the hardware reports an Exception PC
> > (CP0 EPC) of the branch, with a status bit set (StatusBD) to indicate
> > that the exception was for the instruction in the delay slot of the
branch.
> > By convention, if an exception or interrupt prevents the completion of
> > an instruction in a branch delay or forbidden slot, the branch
> > instruction is re-executed and branch instructions must be restartable
> > to permit this. In particular, procedure calls must be restartable. To
> > insure that a procedure call is restartable, procedure calls that have
a
> > delay slot or forbidden slot (branch/jump-and-link instructions) should
> > not use the register in which the return link is stored (usu-ally GPR
> > 31) as a source register. This applies to all branch/jump-and-link
> > instructions that have both a slot (delay or forbidden) and source
> > registers, both for conditions (e.g., BGEZAL or BGEZALC) or for jump
> > targets (JALR).
> >
> > ---
> >
> > I would have expected the behavior match the UNDEFINED description, as
> > Yongbok Kim commented here:
> > https://bugs.launchpad.net/qemu/+bug/1663287/comments/3
> >
> >    branches in a delay slot is "undefined" in the pre-Release
> >    6 architecture. MIPS architectre release 6 defines to signal
> >    Reserved Instruction exceptions for such cases.
> >
> > But it really appears as UNPREDICTABLE.
>

Folks,

Thanks for everyone involved, esp. Philippe for devising the proposal and
citing the manual about UNPREDICTABLE meaning, but I think this is too late
to fix it in 5.0 (too risky), so let's talk about it in 5.0+.

Yours,
Aleksandar

[-- Attachment #2: Type: text/html, Size: 8380 bytes --]