Am Montag, 13. November 2006 10:53 schrieb Simon Marlow:
> Sven Panne wrote:
> > Fri Nov 10 09:16:26 PST 2006 [EMAIL PROTECTED]
> > * Make StablePtr and friends visible, this seems to be necessary for
> > 64bit architectures
> >
> > M ./includes/Rts.h +4
>
> This undoes a previous patch of mine:
>
> Tue Oct 24 10:13:57 BST 2006 Simon Marlow <[EMAIL PROTECTED]>
> * Split GC.c, and move storage manager into sm/ directory
> In preparation for parallel GC, split up the monolithic GC.c file into
> smaller parts. Also in this patch (and difficult to separate,
> unfortunatley):
>
> - Don't include Stable.h in Rts.h, instead just include it where
> necessary.
That's exactly what my patch does, i.e. make the StablePtr C API visible when
compiling via C. ;-) Parts of the C interface for stable pointers is really
needed when compiling user code (because of primops and DsForeign.lhs, IIRC).
On x86_64, StgStablePtr consists of 8 bytes (a void *), but without any
visible prototypes the C compiler assumes 4 bytes (an int). This causes
crashes when e.g. 'foreign import "wrapper"' is used. This can easily be
checked with most examples in the GLUT package, which heavily rely on Haskell
callbacks.
> Could you expand on where the include was necessary? I've been including
> Stable.h in each .c file, rather than in Rts.h. I think the idea was to
> keep dependencies more explicit, rather than have a monolithic Rts.h that
> includes everything. It's not a big deal, but if we go back to including
> Stable.h in Rts.h we should remove it from all the .c files too.
I think that at least the prototypes for deRefStablePtr and getStablePtr have
to be visible through Rts.h, probably more. You could move those prototypes
from Stable.h to Rts.h if this considered better.
A related topic: It would be good to remove the warnings
warning: cast to pointer from integer of different size
when compiling GHC.PrimopWrappers on x86_64, they are probably harmless, but
give me an uneasy feeling.
Cheers,
S.
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
