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.
