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