/[gentoo-x86]/dev-lang/ghc/files/ghc-6.12.3-ia64-storage-manager-fix.patch
Gentoo

Contents of /dev-lang/ghc/files/ghc-6.12.3-ia64-storage-manager-fix.patch

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.1 - (show annotations) (download)
Fri Jul 9 15:03:24 2010 UTC (4 years, 1 month ago) by slyfox
Branch: MAIN
CVS Tags: HEAD
Marked ~ia64 (as now we have ia64 binaries for ghc)
(Portage version: 2.1.8.3/cvs/Linux x86_64)

1 storage manager: preserve upper address bits on 64bit machines (thanks to zygoloid)
2
3 the issue: durin ia64 ghc bootstrap (both 6.10.4 and 6.12.3) I
4 got the failure on stage2 phase:
5 "inplace/bin/ghc-stage2" -H32m -O -H64m -O0 -w ...
6 ghc-stage2: internal error: evacuate: strange closure type 15
7 (GHC version 6.12.3 for ia64_unknown_linux)
8 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
9 make[1]: *** [libraries/dph/dph-base/dist-install/build/Data/Array/Parallel/Base/Hyperstrict.o] Aborted
10
11 I attached gdb and got backtrace:
12
13 Breakpoint 1 at 0x400000000469ec31: file rts/RtsMessages.c, line 39.
14 (gdb) run -B/var/tmp/portage/dev-lang/ghc-6.12.3/work/ghc-6.12.3/inplace/bin --info
15 Starting program: /var/tmp/portage/dev-lang/ghc-6.12.3/work/ghc-6.12.3/inplace/lib/ghc-stage2 -B/var/tmp/portage/dev-lang/ghc-6.12.3/work/ghc-6.12.3/inplace/bin --info
16 [Thread debugging using libthread_db enabled]
17
18 Breakpoint 1, barf (s=0x40000000047915b0 "evacuate: strange closure type %d") at rts/RtsMessages.c:39
19 39 va_start(ap,s);
20 (gdb) bt
21 #0 barf (s=0x40000000047915b0 "evacuate: strange closure type %d") at rts/RtsMessages.c:39
22 #1 0x400000000474a1e0 in evacuate (p=0x6000000000147958) at rts/sm/Evac.c:756
23 #2 0x40000000046d68c0 in scavenge_srt (srt=0x6000000000147958, srt_bitmap=7) at rts/sm/Scav.c:348
24 ...
25
26 > 16:52:53 < zygoloid> slyfox: i'm no ghc expert but it looks like HEAP_ALLOCED_GC(q)
27 > is returning true for a FUN_STATIC closure
28 > 17:18:43 < zygoloid> try: p HEAP_ALLOCED_miss((unsigned long)(*p) >> 20, *p)
29 > 17:19:12 < slyfox> (gdb) p HEAP_ALLOCED_miss((unsigned long)(*p) >> 20, *p)
30 > 17:19:12 < slyfox> $1 = 0
31 > 17:19:40 < zygoloid> i /think/ that means the mblock_cache is broken
32 > 17:22:45 < zygoloid> i can't help further. however i am suspicious that you seem to have pointers with similar-looking low 33
33 > bits and different high 4 bits, and it looks like such pointers get put into the same bucket in
34 > mblock_cache.
35 ...
36 > 17:36:16 < zygoloid> slyfox: try changing the definition of MbcCacheLine to StgWord64, see if that helps
37 > 17:36:31 < zygoloid> that's in includes/rts/storage/MBlock.h
38 And it helped!
39
40 diff --git a/includes/rts/storage/MBlock.h b/includes/rts/storage/MBlock.h
41 index 0943d4c..a113498 100644
42 --- a/includes/rts/storage/MBlock.h
43 +++ b/includes/rts/storage/MBlock.h
44 @@ -126,7 +126,17 @@ extern StgWord8 mblock_map[];
45
46 #define MBC_LINE_BITS 0
47 #define MBC_TAG_BITS 15
48 -typedef StgWord32 MbcCacheLine; // could use 16, but 32 was faster
49 +
50 +#if x86_64_HOST_ARCH
51 +// 32bits are enough for 'entry' as modern amd64 boxes have
52 +// only 48bit sized virtual addres.
53 +typedef StgWord32 MbcCacheLine;
54 +#else
55 +// 32bits is not enough here as some arches (like ia64) use
56 +// upper address bits to distinct memory areas.
57 +typedef StgWord64 MbcCacheLine;
58 +#endif
59 +
60 typedef StgWord8 MBlockMapLine;
61
62 #define MBLOCK_MAP_LINE(p) (((StgWord)p & 0xffffffff) >> (MBLOCK_SHIFT + MBC_LINE_BITS))

  ViewVC Help
Powered by ViewVC 1.1.20