From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2874 invoked by alias); 24 Sep 2012 14:20:09 -0000 Received: (qmail 2670 invoked by uid 48); 24 Sep 2012 14:19:43 -0000 From: "olegendo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/50457] SH2A atomic functions Date: Mon, 24 Sep 2012 14:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: olegendo at gcc dot gnu.org X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status Last reconfirmed CC Resolution Ever Confirmed Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-09/txt/msg01955.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50457 Oleg Endo 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 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. @r1,%0 mov #0,r0 cmp/eq %0,%4 bf 1f mov. %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?