http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457
Oleg Endo <olegendo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Last reconfirmed| |2012-09-24
CC| |kkojima at gcc dot gnu.org
Resolution|INVALID |
Ever Confirmed|0 |1
--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-09-24 14:19:41
UTC ---
Uhm, I've been thinking ....
In fact, the current atomic sequences (-msoft-atomic) are not compatible with
anything but SH3* and SH4*. This is because everything < SH3 (including SH2A)
pushes SR and PC on the stack (R15) when an exception occurs, and for that the
stack pointer must always be valid. The crashes mentioned in the original
description are caused by the invalid stack pointer. I'm sorry for not
noticing this when replying/closing this PR prematurely.
I don't know how linux/glibc have been handling atomic ops on SH2 or SH2A, but
I've got an idea that would work in a bare-metal setup.
Instead of signaling the 'is in atomic sequence' condition through R15, it can
be signaled through a thread local variable. For example a compare_and_swap
sequence might look like this:
mov #(0f-1f),r1 ! sequence length is held in R1
mova 1f,r0
.align 2
mov.l r0,@(#x,gbr) ! enter atomic sequence by setting the
! exit point to the thread
local variable.
! #x is user defined through -m
option
0:
mov.<bwl> @r1,%0
mov #0,r0
cmp/eq %0,%4
bf 1f
mov.<bwl> %3,@%1
1: mov.l r0,@(#x,gbr) ! set thread local variable to nullptr,
! which exits the atomic
sequence.
The check in the exception handling code for the 'is in atomic sequence'
would be:
@(#x,gbr) != 0 && @(0,r15) < @(#x,gbr)
The atomic sequence rewind step in the exception handling code would be:
@(0,r15) = @(#x,gbr) + r1
My assumption here is that gbr points to the execution context
housekeeping structure, which is also accessible from user space. I've briefly
checked the code of glibc and this seems to be the case.
Problems will occur when the gbr is modified by user code (inline asm etc).
So user code should not modify the gbr, or at least do it in a controlled way.
But I think this issue can be ignored for now.
The execution context struct must be modified to hold the additional variable
for atomic sequences.
The thread library / kernel will need a modification (the kernel will need a
modification
on SH2(A) anyway), so that @(#x,gbr) is initialized to zero on thread creation.
Kaz, could you please provide some feedback on this idea?
