What could cause P/Invoke arguments to be out of order when passed?

Question

This is a problem that happens specifically on the ARM, not on x86 or x64. I had this problem reported by a user and was able to reproduce it using UWP on Raspberry Pi 2 via Windows IoT. I've seen this kind of problem before with mismatched calling conventions, but I'm specifying Cdecl in the P/Invoke declaration and I tried explicitly adding __cdecl on the native side with the same results. Here is some info:

P/Invoke declaration (reference):

[DllImport(Constants.DllName, CallingConvention = CallingConvention.Cdecl)]
public static extern FLSliceResult FLEncoder_Finish(FLEncoder* encoder, FLError* outError);

The C# structs (reference):

internal unsafe partial struct FLSliceResult
{
    public void* buf;
    private UIntPtr _size;

    public ulong size
    {
        get {
            return _size.ToUInt64();
        }
        set {
            _size = (UIntPtr)value;
        }
    }
}

internal enum FLError
{
    NoError = 0,
    MemoryError,
    OutOfRange,
    InvalidData,
    EncodeError,
    JSONError,
    UnknownValue,
    InternalError,
    NotFound,
    SharedKeysStateError,
}

internal unsafe struct FLEncoder
{
}

The function in the C header (reference)

FLSliceResult FLEncoder_Finish(FLEncoder, FLError*);

FLSliceResult may be causing some problems because it is returned by value and has some C++ stuff on it on the native side?

The structs on the native side have actual information, but for the C API, FLEncoder is defined as an opaque pointer. When calling the method above on x86 and x64 things work smoothly, but on the ARM, I observe the following. The address of the first argument is the address of the SECOND argument, and the second argument is null (e.g., when I log the addresses on the C# side I get, for example, 0x054f59b8 and 0x0583f3bc, but then on the native side the arguments are 0x0583f3bc and 0x00000000). What could cause this kind of out of order problem? Does anyone have any ideas, because I am stumped...

Here is the code I run to reproduce:

unsafe {
    var enc = Native.FLEncoder_New();
    Native.FLEncoder_BeginDict(enc, 1);
    Native.FLEncoder_WriteKey(enc, "answer");
    Native.FLEncoder_WriteInt(enc, 42);
    Native.FLEncoder_EndDict(enc);
    FLError err;
    NativeRaw.FLEncoder_Finish(enc, &err);
    Native.FLEncoder_Free(enc);
}

Running a C++ app with the following works fine:

auto enc = FLEncoder_New();
FLEncoder_BeginDict(enc, 1);
FLEncoder_WriteKey(enc, FLSTR("answer"));
FLEncoder_WriteInt(enc, 42);
FLEncoder_EndDict(enc);
FLError err;
auto result = FLEncoder_Finish(enc, &err);
FLEncoder_Free(enc);

This logic can trigger the crash with the latest developer build but unfortunately I have not yet figured out how to reliably be able to provide native debug symbols via Nuget such that it can be stepped through (only building everything from source seems to do that...) so debugging is a bit awkward because both native and managed components need to be built. I am open to suggestions on how to make this easier though if someone wants to try. But if anyone has experienced this before or has any ideas about why this happens, please add an answer, thanks! Of course, if anyone wants a reproduction case (either an easy to build one that doesn't provide source stepping or a hard to build one that does) then leave a comment but I don't want to go through the process of making one if no one is going to use it (I'm not sure how popular running Windows stuff on actual ARM is)

EDIT Interesting update: If I "fake" the signature in C# and remove the 2nd parameter, then the first one comes through OK.

EDIT 2 Second interesting update: If I change the C# FLSliceResult definition of size from UIntPtr to ulong then the arguments come in correctly...which doesn't make sense since size_t on ARM should be unsigned int.

EDIT 3 Adding [StructLayout(LayoutKind.Sequential, Size = 12)] to the definition in C# also makes this work, but WHY? sizeof(FLSliceResult) in C / C++ for this architecture returns 8 as it should. Setting the same size in C# causes a crash, but setting it to 12 makes it work.

EDIT 4 I minimalized the test case so that I could write a C++ test case as well. In C# UWP it fails, but in C++ UWP it succeeds.

EDIT 5 Here are the disassembled instructions for both C++ and C# for comparison (though C# I'm not sure how much to take so I erred on the side of taking too much)

EDIT 6 Further analysis shows that during the "good" run when I lie and say that the struct is 12 bytes on C#, the return value gets passed to register r0, with the other two args coming in via r1, r2. However, in the bad run, this is shifted over so that the two args are coming in via r0, r1 and the return value is somewhere else (stack pointer?)

EDIT 7 I consulted the Procedure Call Standard for the ARM Architecture. I found this quote: "A Composite Type larger than 4 bytes, or whose size cannot be determined statically by both caller and callee, is stored in memory at an address passed as an extra argument when the function was called (§5.5, rule A.4). The memory to be used for the result may be modified at any point during the function call." This implies that passing into r0 is the correct behavior as extra argument implies the first one (since C calling convention doesn't have a way to specify the number of arguments). I wonder if the CLR is confusing this with another rule about fundamental 64-bit data types: "A double-word sized Fundamental Data Type (e.g., long long, double and 64-bit containerized vectors) is returned in r0 and r1."

EDIT 8 Ok there is a lot of evidence pointing to the CLR doing the wrong thing here, so I filed a bug report. I hope someone notices it between all the automated bots posting issues on that repo :-S.

Answer 1

The issue I filed on GH has been sitting there for quite some time. I believe that this behavior is simply a bug and no more time needs to be spent looking into it.