On Fri, 13 Dec 2002, Simon Marlow wrote:
> >
> > 59 59
> > 59 59
> > 10 (CONST_NOCAF_STATIC) 10
> > 10 10
> > 33 (IND_STATIC) 4137 (zzz! Max number 64 !)
> > 17 (FUN_STATIC)
> > 33
> > 29
>
> Something is wrong with the heap layout perhaps, or maybe the info tables. I can't
>tell much more from the information above; you'll need to fire up gdb on the
>executable and dig into the contents of the heap and info tables at the point of the
>crash.
>
> Cheers,
> Simon
>
Well, the bug is bounded ( not fixed at all).
RTS::Scheduler.c
GarbageCollect()
get_roots() "GetRoots()"
MarkRoot()
evacuate()
LOOKS_LIKE_GHC_INFO(q)
IS_CODE_PTR(q)
ClosureMacros.h::TEXT_END_SECTION_MARKER_DCL
ClosureMacros.h::TEXT_END_SECTION_MARKER
As pointed Michael Weber in a sparc-unknown-linux porting,the key point is
"gcc on sparc-linux (mips-irix) doesn't mark the beginning of
.data(like "data_start" on i386-linux) . Using etext is definitely wrong
here, since .rodata comes afterwards and therefore etext doesn't cover the infotables
for
static-closures"
bash-2.04$ size nfibI
Section Size Physical Virtual
Address Address
.MIPS.options 128 268435760 268435760
.MIPS.stubs 1188 269119080 269119080
.text 1722540 269120272 269120272
.init 80 270842812 270842812
.fini 56 270842892 270842892
.rodata 266108 270909440 270909440
===> .data 39236 271175552 271175552 <==
...
bash-2.04$ nm nfibI
[7387] | 270842948| 0|SECT |GLOB |DEFAULT |MIPS_TEXT|etext <==
...
[22] | 270909440| 266108|SECT |LOCL |DEFAULT |MIPS_DATA|.rodata
[23] | 271175552| 39236|SECT |LOCL |DEFAULT |MIPS_DATA|.data -border-
[136] | 270909440| 0|SECT |GLOB |DEFAULT |MIPS_DATA|fdata <==
[137] | 270909440| 0|SECT |GLOB |DEFAULT |MIPS_DATA|_fdata <==
No symbol cover ".rodata" section, i.e some info-static closures...
I'll think a *patch*. Michael Weber's (linker script) doesn't semm useful
because I can't use GNU ld.
It May be useful for further designs of Ghc , in order to get a cleaner
portability... (To Mr. Marlow )
Any idea ?
By hardwiring (code lit. 271175552) the code each compilation, I could run
nfibI(35), so I'm in the rigth way.
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
