[Mono-devel-list] More 64 bit changes

[Paolo Molaro]

On 07/02/03 Bernie Solomon wrote:
> 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.

Yes, that code is broken, but your patch is not correct, because it
could cause int64 and doubles to be aligned on 8 byte boundaries,
which is incorrect on x86. so you need something like:

#ifdef __x86__ /* add other archs as appropriate */
#define DOUBLE_ALIGNMENT 4
#define INT64_ALIGNMENT 4
#else
#define DOUBLE_ALIGNMENT 8
#define INT64_ALIGNMENT 8
#endif

And then use INT64_ALIGNMENT or DOUBLE_ALIGNMENT in the function.
The rounding up needs to be done using sizeof (gpointer) as you point
out: since I guess that's what most of the platforms do.
I didn't apply the marshal.c chunks of your patch.

> 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

Thanks for the fix.

> actually think the second thread should actually wait for initialized to
> become true shouldn't it?

No: if initialized was set it can return, if it's not set but
initializing is set it means it's a recursive call from the same thread
that was already initalizing the type and we need to return to avoid a
deadlock.

> 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.

Well, there are interesting issues. For the normal code (and once the
above issues with sizeof(gpointer) and alignement are fixed) there
should be no issue, because the runtime should lay out all the fields as
necessary for the platform. In some cases, though, the marshal code
should insert unaligned. opcode prefixes so that the execution engine
uses the appropriate code that doesn't trigger the unaligned fault
handlers. I'm afraid, though, that that neither mint nor the jit use
the unaligned prefix, yet, but as I said, if the rest of the code is
fixed, you should not hit this case normally.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better