On Wed, 17 May 2023 22:41:16 GMT, Paul Sandoz <psan...@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
