On Tue, 2 May 2023 14:24:39 GMT, Martin Doerr <mdo...@openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little 
>> Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to 
>> get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). 
>> I've kept the related tests disabled for this platform and throw an 
>> exception instead. Note that the ABI doesn't precisely specify variable 
>> argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument 
>> Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. 
>> structs with size not divisible by 8 are not passed correctly (see 
>> `useABIv2` in CallArranger.java). Big Endian is excluded by selecting 
>> `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size 
>> divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I 
>> think arbitrary sizes are not usable on other platforms, either, because 
>> `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: 
>> Resolved after merging of 
>> [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float 
>> Aggregate). The same argument may need to get passed in both, a FP reg and a 
>> GP reg or stack slot (see "no partial DW rule"). This cases are not covered 
>> by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. 
>> This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see 
>> CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to 
>> know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select 
>> between the correct IEEE 754 formats. The register representation in single 
>> FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and 
>> loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer 
>> (with byteSize() == 0) while running TestUpcallScope. Hence, existing size 
>> checks don't work (see MemorySegment.java). As a workaround, I'm just 
>> skipping the check in this particular case. Please check if this makes sense 
>> or if there's a better fix (possibly as separate RFE). Update: This issue is 
>> resolved by 2nd commit.
>
> Martin Doerr has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 32 commits:
> 
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - Prepare for JDK-8304888. (Revert test changes.)
>  - Adaptation for JDK-8303002.
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - Revert unintended formatting changes. Fix comment.
>  - Enable remaining foreign tests.
>  - Adaptations for JDK-8304265.
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - Adaptation for JDK-8305668
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/a8bf2acb...e4ddbda0

> In general the assumption of the linker is that any layouts it is given are 
> correct for the given platform/ABI. i.e. it is up to the user to specify the 
> correct padding (and this is where jextract can help out a lot). We do also 
> check that layouts are 'canonical' now (see #13164 & [1]). I think this 
> already guarantees that the necessary trailing padding is present (constraint 
> 3)? Did you see the discussion at [2] ? I think we already have Big Endian 
> covered?

I had seen that discussion. It appears to work for the TestMiniStruct I had 
uploaded (passed a structure consisting of 3 bytes). However, I'm getting 
failures when passing larger structs which have a size >8, but not divisible by 
8. E.g. 17 tests of TestDowncallScope are failing. The guarantee was not hit.

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

PR Comment: https://git.openjdk.org/jdk/pull/12708#issuecomment-1531709856

Reply via email to