On Thu, 18 May 2023 16:52:15 GMT, Paul Sandoz <[email protected]> wrote:
> Here's the crux of what i am wondering about. Can we specify native linker
> support for a subset of the System V Application Binary Interface (e.g., LP64
> and ILP32 programming models for all non-optional scalar types, sequences of,
> and groups of) such that a developer can write code using the FFM API and it
> will work across all JDK implementations supporting that native linker?
>
> AFAICT the closest we have to that is the table in the Linker doc, and that
> table references C type names. Perhaps we can use C type name as the ABI type
> name for the System V Application Binary Interface? (literally copy the name
> used in Figure 3.1 C column of the ABI specification).
>
> Then can do we the same and specify the equivalent native linker support for
> ABIs of Windows 64/32 and ARM?
Consider that, at the time of writing we support (or might support soon):
* Sysv (Linux and MacOS)
* Aarch64(Linux, MacOs, Windows) - these have actually some ABI differences
(e.g. variadic calls)
* PowerPC (which might come in big/little endian flavors)
* RiscV
That's quite a lot of ABIs and tables to have.
Also, if we wanted to tighten up the spec a little bit, what the user cares
about is some minimum guarantees about the supported ABI types across
platforms. E.g. you don't want a table-per-ABI, precisely because you want to
know (I think): "if I call `linker.canonicalLayout().get("int")`" is this call
guaranteed to succeed?
So, pulling on the string, IMHO we should:
* define which common subset of C types we support (e.g. list the C type names)
- probably the one we use now is a good set;
* Give an example, on x64, of how these types might be realized using layouts
(e.g. current table)
More pulling, the `char16_t` type is probably *not* defined on all ABIs (e.g. I
can't find it here [1]). Which seems to suggest that perhaps canonical layout
should just return mapping from string to lists of layouts, even if
inconvenient?
[1] -
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#arm-c-and-c-language-mappings
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1553401016
