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

[Paul Sandoz]

On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc

I agree focusing on a subset of C types is the way to go. That avoids the unnecessary verbosity of many tables, and we can enumerate the types differing by data model (e.g., LP64 and ILP32). 

As a developer i would like to know for all C-based native linkers (which is all native linkers? what else would they be based on?) if:

1. the C `int` type etc is supported; and
2. whether i can use the `JAVA_INT` layout in my function descriptors, and know it corresponds to a C `int`. 

It seems obvious that i should be able to but AFAICT the specification is more example based, so it's not clear to me if different Java implementations can deviate in such behaviour.

Requiring the use of the C type names in the canonical mapping does help, because then i can more directly ask the C-based linker "Hey what's your canonical layout for the C `char` type?" .

I don't see `char16_t` defined either and i believe that type is an alias for `uint_least16_t`, which is a type of *at least* 16 bits. We need to use a C type of `unsigned short` or `uint16_t`:

- Java `ValueLayout.JAVA_SHORT` <-> C `short`
- Java `ValueLayout.JAVA_CHAR` <-> C `unsigned short`

?

For canonical type names we may want to prefer types specified by the C language over those defined by the C library in standard headers?

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

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1553541814