[Mono-bugs] [Bug 57546][Cri] Changed - PPC: mono/test pinvoke11.exe fails (mono_return_sc1)

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Thu, 21 Oct 2004 17:15:55 -0400 (EDT)


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by grompf@sublimeintervention.com.

http://bugzilla.ximian.com/show_bug.cgi?id=57546

--- shadow/57546	2004-10-21 17:08:39.000000000 -0400
+++ shadow/57546.tmp.2241	2004-10-21 17:15:55.000000000 -0400
@@ -47,6 +47,59 @@
 
 
 ------- Additional Comments From grompf@sublimeintervention.com  2004-10-21 17:08 -------
 Created an attachment (id=13030)
 proposed patch
 
+
+------- Additional Comments From grompf@sublimeintervention.com  2004-10-21 17:15 -------
+The above patch addresses the case of 1 and 2 byte structures which are handled in a 
+special way on MachO/Darwin.  It also introduces arg alignment to 4 bytes on the stack 
+(see the comment about lin alignment; I've left it as 0 for now).
+Some of the if __APPLE__ might apply to lin/ppc as well; but I currently dont have a lin/ppc 
+test box; can you check lupus?
+
+pinvoke11 now gets:
+junglist:~/Documents/Development/mono/CVS/Sources/mono/mono/tests plasma$ 
+mono pinvoke11.exe
+junglist:~/Documents/Development/mono/CVS/Sources/mono/mono/tests plasma$ echo 
+$?
+10
+
+Error level 10 is for marshalling a 3 byte struct.
+
+Reading the MachO ABI, any arg >= 3 bytes that isn't rounded on a word boundary is 
+handled in a special way and has to exist at a specific portion of the stack (offset 28 I 
+believe; take a look at) :
+
+#include <stdio.h>
+
+struct sc1
+{
+        char c[3];
+};
+
+struct sc1 mono_return_sc1 (struct sc1 a) {
+        int i = 0;
+        a.c[0]++;
+}
+
+dissassembled:
+        lbz r5,28(r1)
+        mr r4,r3
+        mr r3,r4
+        addi r0,r5,1
+        stb r0,28(r1)
+        blr
+
+The PPC jit on __APPLE__ is currently aligning the pre-redzone like so
+offset = PPC_MINIMUM_STACK_SIZE; // 24
+offset += m->param_area; 
+offset += 16-1;
+offset &= ~(16-1);
+
+which is giving an offset to start the redzone at 0x30 (48).  Off by 20 bytes.
+
+I've tried moving this around; but it appears that some other storing isn't happening 
+properly in the wrapper function for pinvokes; there will have to be some additional 
+changes to support these types.
+