On Mon, 13 Mar 2023 16:20:22 GMT, Martin Doerr <mdo...@openjdk.org> wrote:
> I guess I should add a couple of Upcalls to my new test. Otherwise, I have > only planned to fix TestArrayStructs. Further changes (and maybe new tests) > can still get done when working on Big Endian / AIX or when there is a demand. Okay. The reason I ask is because we are looking to get started with the JEP PR, but it might be nice to wrap up this PR first, to avoid any merge conflicts. I also have https://github.com/openjdk/jdk/pull/12883 which would need changes to the PPC call arranger/linker as well (though, it's a pretty simple refactor). I'm trying to figure out what the best order to do things in is. > I'm currently wondering about the TestArrayStructs failures. Passing arrays > with up to 7 elements seems to work fine. When I pass 8 elements, the last > element of capturedArgs gets observed as 0. When I pass more than 8 elements, > element 5 and 6 of capturedArgs get observed as 0. DowncallLinker.invokeInterpBindings has the correct args, but UpcallLinker.invokeInterpBindings doesn't receive the correct values as lowLevelArgs. They contain the wrong zeros. The remaining elements look correct. Do you have an idea what could be going wrong? Otherwise, I'll have to continue debugging. This sounds like there might be a mismatch between the Java and native side. I suggest looking at the assembly generated for the native function for the failing case, and seeing if it matches what is generated by CallArranger. Here is also where adding a CallArranger test can be useful (in test/jdk/java/foreign/callarranger), to test whether the resulting bindings match your expectation for that function descriptor. Also, you might want to check the layout the native compiler uses for the particular struct, and verify that it matches the Java side. (i.e. there's no weird padding or something, it's just a struct of 8 bytes). ------------- PR: https://git.openjdk.org/jdk/pull/12708
