[foreign-memaccess+abi] RFR: 8300294: Add tests for by-value unions and structs with nested fixed-length arrays

[Maurizio Cimadamore]

On Wed, 8 Feb 2023 22:30:53 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I've added some tests for by-value unions, structs/unions nested into other structs, and aggregates with nested inline arrays.
>> 
>> These test cases are taken from a fuzzer I wrote a while ago. So, they are a bit random in terms of the generated layouts, but should nonetheless  serve as a basic test for the cases that we miss with TestDowncall/TestUpcall today. This mostly helps give some coverage of the linker's classification code for these cases.
>> 
>> I've also pulled in some test value generation code, which can generate random test values when given a MemoryLayout, allocator and random generator. (if it seems useful, I can re-write the existing tests to use this generation code as well, but I'd like to save that for a followup PR).
>> 
>> Unfortunately, the fallback linker doesn't seem to be able to reliably handle by-value unions. It's a know issue with libffi. I've filed: https://bugs.openjdk.org/browse/JDK-8301800 for now. I've changed the implementation to throw an IAE, which was already specified for `Linker::downcallHandle/upcallStub`: 
>> 
>> https://github.com/openjdk/panama-foreign/blob/f61f3a31af4976d0e64d3bfa72cda95b501e2a7d/src/java.base/share/classes/java/lang/foreign/Linker.java#L232-L235
>> 
>> There was also a bug in the classification of HFAs on AArch64 which I've fixed. The issue was that structs with float/double fields that are nested into arrays or other structs/unions should also be counted as HFAs. But, the correct classification logic only accounted for the 'flat' case, where a struct only contains ValueLayouts.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/TypeClass.java line 80:
> 
>> 78:             } else {
>> 79:                 // padding or value layouts
>> 80:                 out.add(member);
> 
> Note here that groups with padding will be rejected later when each field is checked in `isHomogeneousFloatAggregate`

Does the order in which you collect the layouts matter? E.g. this will do a depth-first visit of the layout tree - I see that the code above does an indexed get on the scalar layout list, so I believe the order does matter.

My impression is that it's ok: the depth-first visit returns layouts in the order in which they are laid out in memory, which seems to make sense for an ABI.

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

PR: https://git.openjdk.org/panama-foreign/pull/780