RFR: 8263512: [macos_aarch64] issues with calling va_args functions from invoke_native [v3]

[Jorn Vernee]

On Thu, 3 Jun 2021 03:28:56 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> macOS on Apple silicon uses slightly different ABI conventions to the
>> standard AArch64 ABI.  The differences are outlined in [1].  In
>> particular in the standard (AAPCS) ABI, variadic arguments may be passed
>> in either registers or on the stack following the normal calling
>> convention.  To handle this, va_list is a struct containing separate
>> pointers for arguments located in integer registers, floating point
>> registers, and on the stack.  Apple's ABI simplifies this by passing all
>> variadic arguments on the stack and the va_list type becomes a simple
>> char* pointer.
>> 
>> This patch adds a new MacOsAArch64 CABI type and MacOsAArch64Linker to
>> represent the new ABI variant on macOS.  StackVaList is based on
>> WinVaList lightly modified to handle the different TypeClasses on
>> AArch64.  The original AArch64Linker is renamed to AapcsLinker and is
>> currently used for all non-Mac platforms.  I think we also need to add a
>> WinAArch64 CABI but I haven't yet been able to test on a Windows system
>> so will do that later.
>> 
>> The macOS ABI also uses a different method of spilling arguments to the
>> stack (the standard ABI pads each argument to a multiple of 8 byte stack
>> slots, but the Mac ABI packs arguments according to their natural
>> alignment).  None of the existing tests exercise this so I'll open a new
>> JBS issue and work on that separately.
>> 
>> Tested jdk_foreign on macOS AArch64, Linux AArch64, and Linux X86_64.
>> 
>> [1] https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms
>
> Nick Gasson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No variadic upcalls
>   
>   Change-Id: Ibf91c570c88be2587e9e23240477c4a5cc56b4c5
>   CustomizedGitHooks: yes

test/jdk/java/foreign/valist/VaListTest.java line 706:

> 704:                     vaList.skip(BigPoint_LAYOUT);
> 705:                     assertEquals((long) vaList.vargAsLong(C_LONG), 42);
> 706:                 })},

Looks like a carrier size mismatch here:


java.lang.IllegalArgumentException: Carrier size mismatch: long != b32[abi/kind=LONG]
        at jdk.incubator.foreign/jdk.internal.foreign.Utils.checkPrimitiveCarrierCompat(Utils.java:111)
        at jdk.incubator.foreign/jdk.internal.foreign.abi.SharedUtils.checkCompatibleType(SharedUtils.java:231)
        at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.windows.WinVaList.read(WinVaList.java:114)
        at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.windows.WinVaList.read(WinVaList.java:109)
        at jdk.incubator.foreign/jdk.internal.foreign.abi.x64.windows.WinVaList.vargAsLong(WinVaList.java:84)
        at VaListTest.lambda$upcalls$58(VaListTest.java:705)
        at jdk.incubator.foreign/jdk.internal.foreign.abi.ProgrammableInvoker.invokeNative(Native Method)
        at jdk.incubator.foreign/jdk.internal.foreign.abi.ProgrammableInvoker.invokeMoves(ProgrammableInvoker.java:290)
        at VaListTest.testUpcall(VaListTest.java:530)


Need to use `C_LONG_LONG` to be cross-platform compatible. (sorry for not noticing this).

Suggestion:

                { linkVaListCB("upcallBigStructPlusScalar"), VaListConsumer.mh(vaList -> {
                    MemorySegment struct = vaList.vargAsSegment(BigPoint_LAYOUT, ResourceScope.newImplicitScope());
                    assertEquals((long) VH_BigPoint_x.get(struct), 8);
                    assertEquals((long) VH_BigPoint_y.get(struct), 16);

                    assertEquals((long) vaList.vargAsLong(C_LONG_LONG), 42);
                })},
                { linkVaListCB("upcallBigStructPlusScalar"), VaListConsumer.mh(vaList -> {
                    vaList.skip(BigPoint_LAYOUT);
                    assertEquals((long) vaList.vargAsLong(C_LONG_LONG), 42);
                })},

-------------

PR: https://git.openjdk.java.net/jdk/pull/3617