[Bug target/82150] Produces a branch prefetch which causes a hang

[Bug target/82150] Produces a branch prefetch which causes a hang

[david.welch at netronome dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150

--- Comment #11 from david.welch at netronome dot com ---
I wish I had know this when I filed this ticket, there is an ARM Errata for
this issue that was issued before or in 2009.  

720247: Speculative Instruction fetches can be made anywhere in the memory map

I have researched this bug on this core and provided a workaround that ARM was
not able or willing.  (put a nop after unconditional branch instructions that
modify the pc like pop {r4,pc}, but not bx lr...,anything other than another
branch instruction that causes a speculative fetch).

So if you require an ARM Errata in order to fix something, there you go it
exists.

It is still present in gcc 10 (has been present all this time).  I have not
examined gcc 11 yet as it has not been formally released.

unsigned int more_fun ( unsigned int );
unsigned int fun ( void )
{
    return(more_fun(0x12344700)+1);
}

Disassembly of section .text:

00000000 <fun>:
   0:   b510            push    {r4, lr}
   2:   4802            ldr     r0, [pc, #8]    ; (c <fun+0xc>)
   4:   f7ff fffe       bl      0 <more_fun>
   8:   3001            adds    r0, #1
   a:   bd10            pop     {r4, pc}
   c:   12344700        .word   0x12344700


.thumb
.inst.n 0x4700


Disassembly of section .text:

00000000 <.text>:
   0:   4700            bx      r0

and there is the speculative execution that causes a read (that can be anywhere
in the address space)


arm-none-eabi-gcc --version
arm-none-eabi-gcc (GCC) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

One could examine everything after a branch like this for another branch as a
real instruction or embedded in the top of the pool a nop may be simpler after
each of the at-risk instructions.

[Bug target/82150] Produces a branch prefetch which causes a hang

[david.welch at netronome dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150

--- Comment #12 from david.welch at netronome dot com ---
I my case this was found with a hang, but the problem exists as a read, which
means it can cause a read to a read sensitive peripheral causing adverse
affects.

[Bug target/82150] Produces a branch prefetch which causes a hang

[david.welch at netronome dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150

--- Comment #13 from david.welch at netronome dot com ---
Very sorry it has been years since I did this research, a simple nop wont fix
it but a branch to self will.

bad

TEST:
        push {r4,lr}
        pop {r4,pc}
        bx r0 /*.hword 0x4700*/
        nop
        nop

bad

TEST:
        push {r4,lr}
        pop {r4,pc}
        nop
        bx r0 /*.hword 0x4700*/
        nop
        nop


good

TEST:
        push {r4,lr}
        pop {r4,pc}
        b .
        bx r0 /*.hword 0x4700*/
        nop
        nop

[Bug target/82150] Produces a branch prefetch which causes a hang

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #14 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
The code generated is architecturally correct.  If your core is prefetching
from addresses that are not valid then this is indicative that the MMU is
incorrectly configured for your system.  Prefetches will NOT be attempted from
unmapped pages, or pages that are mapped as device memory.

So you need to find out why your memory system has not been correctly set up.

There's no bug in GCC here.

[Bug target/82150] Produces a branch prefetch which causes a hang

[david.welch at netronome dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150

david.welch at netronome dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #15 from david.welch at netronome dot com ---
Please read the errata and not blow off this ticket.

The MMU is not being used, this is a verified problem, acknowledge by ARM as
well as being independently discovered.  The problem has been present and known
by ARM for years, as well as being reported a while ago to gnu/gcc.

Use the mmu is not a valid solution to fix a known, demonstrable, bug in the
compiler.

[Bug target/82150] Produces a branch prefetch which causes a hang

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-01-29
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #16 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
What's the erratum number?

[Bug target/82150] Produces a branch prefetch which causes a hang

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82150

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #17 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
OK, I've found the erratum number, it's 720247; but it's specific to the
11MPcore and is fixed in r2p1 silicon.

The erratum workaround description states that there is *no* robust software
fix when the MMU is disabled.  Some hardware fixes on your platform might be
possible, but are off-topic here.  Also, using r2p1 silicon fixes the problem.

Either way, there's nothing we can do in GCC to address this, given the nature
of the problem.