Peter Tanski wrote: > (1) how do I obtain the latest 6.4.3 release? It is no longer on > CVS,
It is in CVS. I tagged it this morning, so you can check out the tag ghc-6-4-3 from CVS. Alternatively, you can grab the 6.4.3 source distribution from here; http://haskell.org/ghc/dist/6.4.3 > (2) For working a debug build of ghc-6.4.2 I had to modify the file > ghc/compiler/nativeGen/RegisterAlloc.hs by adding a deriving > declaration: > > ghc/compiler/nativeGen/RegisterAlloc.hs:158 > > data FreeRegs = FreeRegs !Word32 !Word32 > + deriving (Show) > > This fix was in the 6.6 branch. Is it also now in the 6.4.3 branch? This fix isn't in 6.4.3, sorry. > (3) I cheated and modified the ghc script that invokes the > executable ..lib/ghc-6.4.2/ghc-6.4.2 by inserting a gdb invocation > after the exec statement. (I was working on compiling Crypto with > the original Cabal setup but didn't want to resort to makefiles.): > > # Mini-driver for GHC > exec gdb --args $GHCBIN $TOPDIROPT ${1+"$@"} > > Is there a better way to go about this? I normally create a .gdbinit file with a suitable 'set args' command in the current directory when I'm running gdb on GHC itself. > (4) Would you please elaborate on the problem and the fix? The > problems consistently showed up in ghc/rts/GC.c:threadSqueezeStack, > in the variable frame (note: comments *follow* code: > > (gdb) disas threadSqueezeStack > ... threadSqueezeStack is a red herring: the problem is that two OS threads have mistakenly been allowed into the runtime simultaneously, and they're both trying to execute the same Haskell thread. The bug was in the Capability management, which was wrongly assuming that pthread_cond_wait() would only wake up after an explicit pthread_cond_signal(), but this is not the case. Some OSs exhibit spurious wakeups of pthread_cond_wait() more than others, it seems. The problem was pretty obvious from the +RTS -Ds output, incedentally. However getting the bug ro reproduce with +RTS -Ds on was a bit tricky. > (5) One other avenue I was exploring was the use of Zero Length > Arrays (ZLA's) and potential gcc bugs (a few of this sort have been > noticed in gcc-3.3 through 4.0). Why do you use ZLA's in the code? To support variable-length structures, it's a common technique. The FLEXIBLE_ARRAY macro is used to work around portability issues. > The reasons not to are: > > a. ZLA's are largely supported by GNU extensions. > As noted in the GCC manual, Section 5.12, at > http://gcc.gnu.org/ > onlinedocs/gcc/Zero-Length.html : "A structure containing a flexible > array member, or a union containing such a structure (possibly > recursively), may not be a member of a structure or an element of an > array. (However, these uses are permitted by GCC as extensions.)" > You are therefore forced to include structures > containing ZLA's as > pointers-to-structures, for example: >> # 280 "ghc/includes/InfoTables.h" >> typedef struct _StgInfoTable { >> StgClosureInfo layout; >> StgHalfWord type; >> StgHalfWord srt_bitmap; >> StgCode code[]; >> } StgInfoTable; >> # 44 "ghc/includes/Closures.h" >> typedef struct { >> const struct _StgInfoTable* info; >> } StgHeader; > > b. the C sizeof() operator does not correctly report > the size of > structures containing ZLA's, so sizeof(StgInfoTable) reports 8, not > 12, 8 is the correct size for StgInfoTable (on a 32-bit machine). Why do you think it should be 12? > although the gcc compiler correctly produces the assembler for > manipulating such a structure: > > 0x00c246c0 <threadSqueezeStack+88>: addi r9,r2,-12 > ; (((StgRetInfoTable *)(((StgClosure > *)frame)->header.info) - 1)) > ; the -12 is the size of StgInfoTable Actually this is manipulating a pointer to StgRetInfoTable, which does indeed have size 12. > So macros such as ghc/includes/TSO.h:TSO_STRUCT_SIZE can't simply be > defined as > >> #define TSO_STRUCT_SIZE sizeof(StgTSO) > > and gdb has trouble accessing the members of the structure: > > (gdb) p *tso > $30 = { > header = { > info = 0xaf5ff0 > }, > link = 0xded718, > mut_link = 0xded71c, > global_link = 0x2bce000, > what_next = 1, > why_blocked = 11, > block_info = { > closure = 0x0, > tso = 0x0, > fd = 0, > target = 0 > }, > blocked_exceptions = 0xded718, > id = 2, > saved_errno = 25, > main = 0x0, > trec = 0xded714, > stack_size = 242, > max_stack_size = 2080754, > sp = 0x2bddc78 > } > # note the lack of member tso.stack That's fine, we don't expect to see the stack member, because gdb doesn't know its size. > Finally, if there are alignment issues, wouldn't that be better > controlled explicitly through pragmas? Could you elaborate a bit? Where do you want to use alignment pragmas, and what would they buy us? Cheers, Simon _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
