[Mono-list] Porting to Linux on S/390

[Paolo Molaro]

On 09/26/02 Ferguson, Neale wrote:
> ** (process:17763): WARNING **: System.IO.SeekOrigin has unknown value 0x30
> 
> 
> ** (process:17763): WARNING **: System.IO.SeekOrigin has unknown value 0x31
> Compilation failed: 1 error(s), 0 warnings
> ** (process:17763): WARNING **: System.IO.SeekOrigin has unknown value 0x5b

The arguments to this function:

gint64
ves_icall_System_IO_MonoIO_Seek (HANDLE handle, gint64 offset, gint32 origin);

are marshaled incorrectly. HANDLE is a pointer, so, if you're on a 32
bit system that requires int64 values to be placed in 8-byte aligned
memory or in even-odd input registers, you'll get errors as the above
if you instead placed them sequentially (after handle).
So, check that you handle that case according to the calling convention
on your platform in tramp.c.

> Could someone explain for either arm or x86 what they are producing for
> mono_create_method_pointer? 
> What things are on the stack or in registers on entry to the emitted code
> they produce (and any
> register conventions they adopted)?

The arguments arrive to that function according to the platform calling
convention. So, for example, on linux/x86 they will be all on the stack,
on sparc, they will be part in the input registers and part on the stack
etc. So it's not a mint-specific convention, but the platform convention
that applies in this case.
mono_create_method_pointer() needs to take them from the
platform-specific position and put them in a stackval array and set
the MonoInvocation fields so that ves_exec_method () can be called on
it. After ves_exec_method () returns, it must marshal back the results
according to the platform-specific convention:
x86 returns integers in EAX, longs in EAX:EDX etc., sparc in $i0[, $i1]
etc.

lupus

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