[foreign-memaccess+abi] RFR: 8275332: Variadic functions don't work on Linux/AArch64 [v2]

[Nick Gasson]

On Wed, 20 Oct 2021 13:09:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Well I did think about that, but at the moment CallArranger is just a bag of static methods: we'd need to refactor it quite a bit to fit it into that pattern. 
>> 
>> Perhaps (an AArch64 extension of) AbiDescriptor is the right place to store this? That already stores information like stack alignment, shadow space, etc. We'd then have a `MACOS_C` and `LINUX_C` instead of the single `C` we have now, and then pass that into `getBindings()`, etc.
>> 
>>> If I'm right this is the only place where something different needs to happen for the two ABIs?
>> 
>> Actually I think there's one more case we don't handle correctly at the moment but isn't covered by the existing tests:
>> 
>> 
>> void f(int, int, int, int, int, int, int, int, char x, short y);
>> 
>> 
>> In the standard ABI `x` and `y` get spilled to the stack as eight byte quantities (as if they were assigned to a register and then spilled) but in the Mac ABI they are spilled to the stack with their original size and natural alignment. So we need another flag somewhere to handle that difference. I'll make a JBS ticket for it.
>
> Maybe I'm wrong, but it doesn't seem like the refactoring would be that big. After all, the public API of CallArranger is the two static methods arrangeUpcall/Downcall. So, from a client perspective that is the only change. CallArranger could provide two already-made constants, which will give you a call arranger for linux or mac, so that clients won't need to instantiate a new call arranger all the time. This should keep the number of changes in clients under control?

@mcimadamore Yes you're right it's not a big change at all. What do you think of the latest version?

@JornVernee I can take look at implementing the optimised upcall stubs.

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

PR: https://git.openjdk.java.net/panama-foreign/pull/601