#1362: Fix PPC Mac OS X memory access problem in includes/SMP.h
-----------------------------+----------------------------------------------
Reporter: thorkilnaur | Owner: thorkilnaur
Type: bug | Status: new
Priority: normal | Milestone:
Component: Runtime System | Version: 6.7
Severity: normal | Keywords:
Difficulty: Unknown | Os: MacOS X
Testcase: | Architecture: powerpc
-----------------------------+----------------------------------------------
The following session uses a recently pulled ghc HEAD which has been built
with {{{-debug}}}:
{{{
$ gdb /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-HughesPJ-
wrong-fill-indent-20070506_1304/ghc/compiler/stage2/ghc-6.7.20070513
...
(gdb) run -B/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-
HughesPJ-wrong-fill-indent-20070506_1304/ghc
Starting program: /Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-
HughesPJ-wrong-fill-indent-
20070506_1304/ghc/compiler/stage2/ghc-6.7.20070513
-B/Users/thorkilnaur/tn/GHCDarcsRepository/ghc-HEAD-for-HughesPJ-wrong-
fill-indent-20070506_1304/ghc
Reading symbols for shared libraries ..+. done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00cb2744
0x00d8f5e8 in xchg (p=0x2dff000, w=13313840) at ../includes/SMP.h:74
74 __asm__ __volatile__ (
(gdb) where
#0 0x00d8f5e8 in xchg (p=0x2dff000, w=13313840) at ../includes/SMP.h:74
#1 0x00d8f564 in lockClosure (p=0x2dff000) at ../includes/SMP.h:185
#2 0x00d8f0dc in threadStackOverflow (cap=0x1103b00, tso=0x2dff000) at
Schedule.c:2762
#3 0x00d8d75c in scheduleHandleStackOverflow (cap=0x1103b00,
task=0x2b00430, t=0x2dff000) at Schedule.c:1643
#4 0x00d8c700 in schedule (initialCapability=0x1103b00, task=0x2b00430)
at Schedule.c:681
#5 0x00d8e974 in scheduleWaitThread (tso=0x2d80800, ret=0x0,
cap=0x1103b00) at Schedule.c:2466
#6 0x00e8aff0 in rts_evalLazyIO (cap=0x1103b00, p=0x10119d8, ret=0x0) at
RtsAPI.c:510
#7 0x00c0ae20 in main (argc=2, argv=0xbffff600) at Main.c:105
(gdb) info threads
3 process 5257 thread 0x2003 0x9002c548 in semaphore_wait_signal_trap
()
2 process 5257 thread 0x20f 0x9001fa0c in select ()
* 1 process 5257 local thread 0xf03 0x00d8f5e8 in xchg (p=0x2dff000,
w=13313840) at ../includes/SMP.h:74
(gdb) quit
The program is running. Exit anyway? (y or n) y
error while killing target (killing anyway): assertion failure on line 274
of "/SourceCache/gdb/gdb-437/src/gdb/macosx/macosx-nat-inferior-util.c" in
function "macosx_inferior_suspend_ptrace": status.value.sig ==
TARGET_SIGNAL_STOP
warning: error on line 1729 of "/SourceCache/gdb/gdb-437/src/gdb/macosx
/macosx-nat-inferior.c" in function "macosx_kill_inferior_safe": (os/kern)
failure (0x5x)
$
}}}
The memory access error occurs in the function {{{xchg}}} in
{{{libraries/SMP.h}}}, here is a disassembly produced by gdb:
{{{
(gdb) disassemble xchg
Dump of assembler code for function xchg:
0x00d8f5c8 <xchg+0>: stmw r30,-8(r1)
0x00d8f5cc <xchg+4>: stwu r1,-64(r1)
0x00d8f5d0 <xchg+8>: mr r30,r1
0x00d8f5d4 <xchg+12>: stw r3,88(r30)
0x00d8f5d8 <xchg+16>: stw r4,92(r30)
0x00d8f5dc <xchg+20>: lwz r2,92(r30)
0x00d8f5e0 <xchg+24>: lwz r0,88(r30)
0x00d8f5e4 <xchg+28>: lwarx r0,r0,r0
0x00d8f5e8 <xchg+32>: stwcx. r2,r0,r0
0x00d8f5ec <xchg+36>: bne- 0xd8f5e4 <xchg+28>
0x00d8f5f0 <xchg+40>: stw r0,24(r30)
0x00d8f5f4 <xchg+44>: lwz r0,24(r30)
0x00d8f5f8 <xchg+48>: mr r3,r0
0x00d8f5fc <xchg+52>: lwz r1,0(r1)
0x00d8f600 <xchg+56>: lmw r30,-8(r1)
0x00d8f604 <xchg+60>: blr
End of assembler dump.
}}}
The problem is in {{{xchg+28}}}-{{{xchg+36}}} which is generated from this
code
in {{{includes/SMP.h}}}:
{{{
INLINE_HEADER StgWord
xchg(StgPtr p, StgWord w)
{
StgWord result;
#if i386_HOST_ARCH || x86_64_HOST_ARCH
...
#elif powerpc_HOST_ARCH
__asm__ __volatile__ (
"1: lwarx %0, 0, %2\n"
" stwcx. %1, 0, %2\n"
" bne- 1b"
:"=r" (result)
:"r" (w), "r" (p)
);
#elif sparc_HOST_ARCH
...
#endif
return result;
}
}}}
What happens is that gcc decides to allocate register {{{r0}}} to both
{{{result}}} and {{{p}}}. And that leads to interesting results.
The attached patch solves the problem by specifying the register assigned
to {{{result}}} as "early clobbered".
Best regards
Thorkil
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/1362>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
