RFR: 8308293: A linker should expose the layouts it supports [v2]

[Maurizio Cimadamore]

On Thu, 18 May 2023 16:52:15 GMT, Paul Sandoz <psandoz at openjdk.org> 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