[Mono-devel-list] More 64 bit changes

[Bernie Solomon]

Sorry I didn't get some of these changes in earlier... I have had the first
two below for a while though I have not noticed any other struct mismatches
myself other than remote_stack_index....

I attach some further changes to the metadata directory for 64 bits - though
some of them are needed on HP because it is big endian unlike alphas. Also
there are a couple of gcc-isms which these cover too....

There are a couple of things I am not sure about.

The rounding up to just 4 byte boundaries in mono_type_native_stack_size for
value types doesn't look general enough to me (as commented) though I
haven't fallen over it as yet.

mono_runtime_class_init checks for "initializing" and "initialized" but if
it returns early it would leave the domain locked. I have unlocked it but I
actually think the second thread should actually wait for initialized to
become true shouldn't it?

In mono_marshal_type_size I have changed the alignments of 8 byte values so
they are naturally aligned on HP. Things crash without this. However is this
right or should it be that code generates the same binary data on all
platforms which means more testing on whether unaligned access is allowed in
code that manipulates data using the results of this routine.

Bernie Solomon

----- Original Message ----- 
From: "Paolo Molaro" <lupus at ximian.com>
To: "Laramie Leavitt" <lar at leavitt.us>
Cc: <mono-devel-list at lists.ximian.com>
Sent: Wednesday, July 02, 2003 4:35 AM
Subject: Re: [Mono-devel-list] Re: Alpha corlib mismatched sizes. (64-bit
issues)


> On 07/01/03 Laramie Leavitt wrote:
> > Laramie Leavitt said:
> > > One of the problems is verify.c, around line 2560
> [...]
> > > change to:
> > > if( klass->valuetype )
> > > struct_offset = 2 * sizeof( void * );
>
> I used sizeof (MonoObject) for this change.
>
> > gint32     *remote_stack_index;
> > gint32      hresult;
> > MonoString *source;
> > } MonoException;
> >
> > We see that for some reason the remote_stack_index appears to
> > be only 4 bytes, and then 4 bytes for the hresult.
>
> I think the '*' is a typo, removing it is the correct fix.
>
> > And on to the other case:
> >
> > typedef struct {
> > MonoObject obj;
> > MonoImage  *image;
> > MonoReflectionAssembly *assembly;
> > MonoString *fqname;
> > MonoString *name;
> > MonoString *scopename;
> > gboolean is_resource;
>
> This should be MonoBoolean: I committed the fix, though I'm not sure
> it solves your issue: MonoBoolean is 8 bits, gboolean is an int, so I
> guess 32 bits on your alpha, but either way the structure should still
> be padded to the next 8 bytes.
> Are you using a current corlib (like from the 0.25 release)?
> Check that the following command returns a line:
> monodis --fields corlib.dll |grep is_resource
> If it return nothing you have an old corlib, if it returns a line I
> guess the bug is in the field layout code (class.c).
>
> On 07/01/03 Laramie Leavitt wrote:
> > The verify.c change prints out all mismatched values instead of only the
> > first one, which I find helpful.  Someone will probably want to use
> > g_printf( ... ) there,
> > though.
>
> I made it use a GString and concat all the results. Thanks for the
> patch.
>
> lupus
>
> -- 
> -----------------------------------------------------------------
> lupus at debian.org                                     debian/rules
> lupus at ximian.com                             Monkeys do it better
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: metadata.diffs
Type: application/octet-stream
Size: 7695 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20030702/6e8250e2/attachment.obj