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

[Maurizio Cimadamore]

On Wed, 17 May 2023 22:41:16 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> So maybe this comes down to the linker supporting a subset ABI's data types, and that subset might increase over time, but never decrease? In this respect could we present a table for each supported linker ABI listing the ABI type and its canonical layout type? (in practice it might just be one table with noted adjustments.)

I see what you mean and I'm not sure about this. On the one hand, having a set of "trusted" type names would be handy - but I don't know how much commitment we want to put in there? I'm also a bit skeptical at listing all possible ABIs, since I suspect the set of supported platforms will change quickly.

Is what you are after some kind of guarantee of "at least these type names will be available" ?

As for a linker possibly having multiple different layouts for the same ABI type, that is true, and, in a way, already the case with ValueLayout.OfChar/ValueLayout.OfShort. I worked around that by using different type names - e.g. `int16_t` and `char16_t`. 

For more exotic types which might be modeled initially opaquely with MemorySegment, and later on with some other ValueLayout.OfFooBar, I believe we'd need to provide a way to go from the opaque layout to the less opaque one.

The other option would be to admit that a single ABI type can map to multiple layouts, and have `Map<String, List<MemoryLayout>>`. It seemed a bit on the convoluted side of things (esp. given that we can get away without it, at least in this patch), but if you think that would be more robust, I can change that.

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

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