On Fri, 16 Oct 2026 15:58:14 GMT, Jorn Vernee <[email protected]> wrote:
> Currently we do not directly support unsigned types in the Linker. The > javadoc has this to say about it: > >> A native linker typically does not provide canonical layouts for C's >> unsigned integral > types. Instead, they are modeled using the canonical layouts associated with > their > corresponding signed integral types. For instance, the C type `unsigned long` > maps to the canonical layout for `code long`. > > This was done under the earlier assumption that ABIs treat signed and > unsigned types the same. However, it turns out that we missed certain cases > where this does matter for some ABIs. More concretely: > > - Mac x64 and AArch64 ABIs require integral types smaller than `int` to be > widened to `int` before being passed to a function > [1](https://developer.apple.com/documentation/xcode/writing-64-bit-intel-code-for-apple-platforms), > > [2](https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms). > Clang even extends this behavior to Linux x64 (although this appears to be a > bug) > [3](https://mail.openjdk.org/archives/list/[email protected]/message/RJNMKNUXN7R5PSJETZKX3PMBJ7P6GYJG/). > - RISCV requires arguments smaller than XLEN to be extended to 32 bits > according to their sign, and then sign extended to XLEN > [4](https://docs.riscv.org/reference/abi/v1.0/riscv-cc-procedure-calling-convention.html). > - PowerPC requires small integer types (char, short, int, long, enum) to be > extended to long > [5](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html#PARAM-PASS). > > In order to address these use cases we need to attach a bit of extra > information to a linkage request that indicates the signedness of certain > arguments. For this patch, we've chosen to attach that information directly > to the argument layouts through a newly introduced `boolean isSigned()` > method on a new `ValueLayout` subclass `OfIntegral` that is implemented by > `OfByte`, `OfShort`, `OfInt`, and `OfLong`. > > This information is potentially used by the linker to implement the correct > extension. In cases where it doesn't affect the way functions are linker the > information is erased in order to provide more efficient caching, since > signed and unsigned types can share the same downcall handle in that case. > > Testing: `jdk_foreign` test suite on Windows/Linux/Mac-x64, > Mac/Linux-AArch64, Linux-x64 using the fallback linker. > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). I think `MemoryLayout::equals/hashCode` need updating? src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 128: > 126: * An integral value layout models an integral data type. > 127: * <p> > 128: * Values represented by {@linkplain OfIntegral integral} layouts I think this should be less ABI centric and more definition-oriented. First line is ok -- this is for modelling integral data types. Fine. Then, we should say that an integral value has signedness -- that is it can model both signed, or unsigned values. Then we should say that signedness doesn't affect memory access operation, but it's useful when converting a value corresponding to an integral layout to a wider carrier (e.g. OfInt to long), in which case there's two option: a cast or Long::xyz. After we said all this, we might want to drop a brief note that native Linker might use signedness to model C unsigned types, but I'm on the fence here as there's normally not many references from this javadoc to the Linker. ------------- PR Review: https://git.openjdk.org/jdk/pull/33417#pullrequestreview-5685458182 PR Review Comment: https://git.openjdk.org/jdk/pull/33417#discussion_r4402693145
