RISC-V - Potential Interop Issues/Considerations

[tannergooding]

The signedness of char in C is implementation defined:

• On Windows x86, x64, and Arm64 its signed: [-128, +127]
• On Unix x86 and x64 its signed: [-128, +127]
• On Unix Arm64 its unsigned: [0, 255]

This fine most of the time because the ABI for these scenarios only cares about the lowest 8 register-bits. The upper bits of the register are left undefined and the callee must explicitly zero or sign-extend the value itself.

On Unix RISC-V, it is also unsigned: [0, 255]. However, the ABI requires the caller to zero/sign-extend the type to fill the entire register instead and this represents a new consideration for interop code.

In particular, this means that all interop signatures must exactly match the signedness as defined by native code. If the underlying C API takes uint, then passing in int is invalid and will cause downstream failures on 64-bit platforms. The same is true for short vs ushort or byte vs sbyte on 32-bit and 64-bit platforms.

For a type like char where the signedness is not well-defined, this means that you can no longer define a single interop signature that works for all combinations of [Windows, Unix] and [x86, x64, Arm32, Arm64, RISC-V].

Given that there is some recent push from the community to add RISC-V support, this is going to become a more prevalent consideration for .NET both in the interop bindings exposed as well as in how to rationalize the handling of C char across platforms.

[tannergooding]

CC. @jkoritzinsky, @AaronRobinsonMSFT, @jkotas, @lambdageek

Would appreciate your input on this and potential directions that should be considered here.

[jkotas]

The signedness of char in C is implementation defined:

Moreover, the default can be modified using compiler switches (-fsigned-char vs. -funsigned-char in clang). It sounds similar to the SIMD calling convention problem on Unix where the ABI can be also modified using compiler switches.

LoongArch has this problem as well. @shushanhf Have you ever run into these sign mismatches in interop?

[jkotas]

The simplest answer for interop with types that have unstable ABIs is that you have to wrap it in a method with stable ABI, and P/Invoke that.

[tannergooding]

the default can be modified using compiler switches (-fsigned-char vs. -funsigned-char in clang).

Worth noting the same exists in MSVC. I don't believe doing so is particularly supported, however, as you're liable to encounter various bugs due to accidental zero/sign extension when upcasting (which can easily result in invalid or incorrect inputs to other functions).

[shushanhf]

The signedness of char in C is implementation defined:

Moreover, the default can be modified using compiler switches (-fsigned-char vs. -funsigned-char in clang). It sounds similar to the SIMD calling convention problem on Unix where the ABI can be also modified using compiler switches.

LoongArch has this problem as well. @shushanhf Have you ever run into these sign mismatches in interop?

No, at least the LoongArch64 is OK during the last two years.

For LoongArch, https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html
For all base ABI types of LoongArch, the char datatype is signed by default.

While for RISC-V, https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc
C/C++ type representations, char is unsigned.

For AArch64, the char is default unsiged byte, but the signed char is signed byte.
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#data-types