OK. I could use some help here.
I think I see what is going on with failing unit test FFIPluginTests>>testPoint4
I am not sure yet how to deal with it.
Looking at the code in gdb, ffiTestStructBig() expects the 4 int values of pt1 in regiters x0,x1 and pt2 in x2,x3 and result p3 returned as x0,x1.
That's right. Read (very carefully) section 5.4.2 Parameter Passing Rules of Procedure Call Standard for the ARM 64-bit Architecture. It states in Stage B that a composite type is only padded and passed in memory if:
B.1 If the argument type is a Composite Type whose size cannot be statically determined by both the caller and the callee, the argument is copied to memory and the argument is replaced by a pointer to the copy. (There are no such types in C/C++ but they exist in other languages or in language extensions).
B.3 If the argument type is a Composite Type that is larger than 16 bytes, then the argument is copied to memory allocated by the caller and the argument is replaced by a pointer to the copy.
and it states in Stage C that:
C.10 If the argument is a Composite Type and the size in double-words of the argument is not more than 8 minus NGRN, then the argument is copied into consecutive general-purpose registers, starting at x[NGRN]. The argument is passed as though it had been loaded into the registers from a double-word- aligned address with an appropriate sequence of LDR instructions loading consecutive registers from memory (the contents of any unused parts of the registers are unspecified by this standard). The NGRN is incremented by the number of registers used. The argument has now been allocated.
So the code in ThreadedARM64FFIPlugin>>ffiCallOutTo:SpecOnSTack:in: and ffiReturnStruct:ofType:in: must obey these (rather tricky and inconvenient) marshaling rules. That's life :-)
The call, however, seems to be putting a pointer to an allocated pt3 in x0, pt1 values in x1,x2 and pt2 values in x3,x4.
So I am looking at ThreadedARM64FFIPlugin>>ffiCallOutTo:SpecOnSTack:in: and ffiReturnStruct:ofType:in: but have not yet worked through the logic of the niggly bits.
So I be deep into the steenking pile, mon!
Well, it might seem like that. Optimization all cost always makes things more difficult, but there are claimed benefits ;-)
Any insights thrown over the wall would be appreciated.
The x86 has somewhat less ambitious rules (except early drafts that gave me headaches in the VisualWorks VM), but also passes small structs in registers. See ThreadedX64SysVFFIPlugin>>#ffiPushStructure:ofSize:typeSpec:ofLength:in:. That method passes small structures in registers and points to the relevant section of the SysV calling convention that specifies the behavior.
As encouragement let me say that this is the most difficult part of the process, so once you have this solved you will have passed the summit. Since it's the last thing you;'re working on anyway that might not be comfort un less you get a high out of conquering a challenge (which I hope and suspect you do).
If you get stuck I can try and find some time to set up may 64-bit ARM and jump into the pre-methane pool with you ;-)
One might think that a dry suit is appropriate garb, but sitting in them for long periods of time gets sweaty. Just use a clothes peg over the nose.
Locked
