diff mbox series

riscv: Add big-endian support to string-fzi.h.

Message ID 20260603135155.619826-1-jovan.dmitrovic@htecgroup.com (mailing list archive)
State New
Headers
Series riscv: Add big-endian support to string-fzi.h. |

Checks

Context Check Description
redhat-pt-bot/TryBot-apply_patch success Patch applied to master at the time it was sent
linaro-tcwg-bot/tcwg_glibc_build--master-arm success Build passed
redhat-pt-bot/TryBot-32bit success Build for i686
linaro-tcwg-bot/tcwg_glibc_build--master-aarch64 success Build passed
linaro-tcwg-bot/tcwg_glibc_check--master-aarch64 success Test passed
linaro-tcwg-bot/tcwg_glibc_check--master-arm success Test passed

Commit Message

Jovan Dmitrovic June 3, 2026, 1:52 p.m. UTC 
  Functions index_first and index_last should depend on endianness,
considering we are looking at raw bytes.

ChangeLog:

        * sysdeps/riscv/string-fzi.h (index_first): Add big-endian
        implementation.
        (index_last): Likewise.
---
 sysdeps/riscv/string-fzi.h | 68 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 68 insertions(+)

Comments

Florian Weimer June 8, 2026, 1:33 p.m. UTC | #1 
* Jovan Dmitrovic:

> Functions index_first and index_last should depend on endianness,
> considering we are looking at raw bytes.

Does big-endian RISC-V really work?  I believe there's missing endianess
translation for compat mode for the affinity system calls right now.

What's the status of the port in Linux and the GNU toolchain?

Thanks,
Florian
Carlos O'Donell June 8, 2026, 1:33 p.m. UTC | #2 
On 6/3/26 9:52 AM, Jovan Dmitrovic wrote:
> Functions index_first and index_last should depend on endianness,
> considering we are looking at raw bytes.

Is RISC-V BE officially supported by the ecosystem at large?

We only support 2 LE variants in glibc's official ABI list:
https://sourceware.org/glibc/wiki/ABIList#RISC-V
Jovan Dmitrovic June 10, 2026, 2:32 p.m. UTC | #3 
Hello everyone,
thank you for the replies. We should be able to see big-endian be
introduced into psABI in the near future:

https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/470

There are efforts across the board in order to introduce
big-endian RISC-V (GCC and qemu already have support for BE).
So I've sent this patch in order to get this process underway
for glibc as well. There are some things that are definitely
missing, but I will be sending patches as I go.

Regards,
Jovan

On 6/8/26 15:33, Carlos O'Donell wrote:
> On 6/3/26 9:52 AM, Jovan Dmitrovic wrote:
>> Functions index_first and index_last should depend on endianness,
>> considering we are looking at raw bytes.
>
> Is RISC-V BE officially supported by the ecosystem at large?
>
> We only support 2 LE variants in glibc's official ABI list:
> https://sourceware.org/glibc/wiki/ABIList#RISC-V
>
> -- 
> Cheers,
> Carlos.
>
Adhemerval Zanella Netto June 10, 2026, 3:56 p.m. UTC | #4 
What about Linux support? Last time I checked there is no option for
CPU_BIG_ENDIAN on arch/riscv and I recall that Linus was not very
enthusiastic about it.

Also, the pull request also states that BE support is not yet complete
on gcc [1], is that the case?

[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/470#issuecomment-4610611607

On 10/06/26 11:32, Jovan Dmitrovic wrote:
> Hello everyone,
> thank you for the replies. We should be able to see big-endian be
> introduced into psABI in the near future:
> 
> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/470
> 
> There are efforts across the board in order to introduce
> big-endian RISC-V (GCC and qemu already have support for BE).
> So I've sent this patch in order to get this process underway
> for glibc as well. There are some things that are definitely
> missing, but I will be sending patches as I go.
> 
> Regards,
> Jovan
> 
> On 6/8/26 15:33, Carlos O'Donell wrote:
>> On 6/3/26 9:52 AM, Jovan Dmitrovic wrote:
>>> Functions index_first and index_last should depend on endianness,
>>> considering we are looking at raw bytes.
>>
>> Is RISC-V BE officially supported by the ecosystem at large?
>>
>> We only support 2 LE variants in glibc's official ABI list:
>> https://sourceware.org/glibc/wiki/ABIList#RISC-V
>>
>> -- 
>> Cheers,
>> Carlos.
>>
Jeffrey Law June 11, 2026, 4:18 p.m. UTC | #5 
On 6/10/2026 9:56 AM, Adhemerval Zanella Netto wrote:
> What about Linux support? Last time I checked there is no option for
> CPU_BIG_ENDIAN on arch/riscv and I recall that Linus was not very
> enthusiastic about it.
>
> Also, the pull request also states that BE support is not yet complete
> on gcc [1], is that the case?
>
> [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/470#issuecomment-4610611607
There's a bit of a chicken and the egg problem here.  We need fixes in 
various places before we can test the GCC bits, including QEMU and GLIBC.

I don't personally think that BE RISC-V is terribly interesting, but I 
wouldn't block its progress just because Linus doesn't like it. So if 
folks are going to step up to make work, maintain it over time, etc then 
we should enable them to do that.

jeff
Jovan Dmitrovic June 12, 2026, 12:44 p.m. UTC | #6 
On 6/11/26 18:18, Jeffrey Law wrote:
> On 6/10/2026 9:56 AM, Adhemerval Zanella Netto wrote:
>> What about Linux support? Last time I checked there is no option for
>> CPU_BIG_ENDIAN on arch/riscv and I recall that Linus was not very
>> enthusiastic about it.
>>
>> Also, the pull request also states that BE support is not yet complete
>> on gcc [1], is that the case?
>>
>> [1] 
>> https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/470#issuecomment-4610611607
> There's a bit of a chicken and the egg problem here.  We need fixes in
> various places before we can test the GCC bits, including QEMU and GLIBC.
>
> I don't personally think that BE RISC-V is terribly interesting, but I
> wouldn't block its progress just because Linus doesn't like it. So if
> folks are going to step up to make work, maintain it over time, etc then
> we should enable them to do that.
>
> jeff

Thanks Jeff for your support, our team is interested in making this work.

Once the psABI proposal is finalized, we will post patches for both GCC 
and LLVM backend,
considering we merged the LLVM codegen support for RISC-V last year [1].

Also, QEMU support is finalized [2], we are only waiting for that series
to be merged to master.

Regards,
Jovan

[1] https://github.com/llvm/llvm-project/pull/172668
[2] https://lists.nongnu.org/archive/html/qemu-devel/2026-05/msg07505.html
Adhemerval Zanella Netto June 12, 2026, 12:53 p.m. UTC | #7 
On 11/06/26 13:18, Jeffrey Law wrote:
> 
> 
> On 6/10/2026 9:56 AM, Adhemerval Zanella Netto wrote:
>> What about Linux support? Last time I checked there is no option for
>> CPU_BIG_ENDIAN on arch/riscv and I recall that Linus was not very
>> enthusiastic about it.
>>
>> Also, the pull request also states that BE support is not yet complete
>> on gcc [1], is that the case?
>>
>> [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/470#issuecomment-4610611607
> There's a bit of a chicken and the egg problem here.  We need fixes in various places before we can test the GCC bits, including QEMU and GLIBC.
> 
> I don't personally think that BE RISC-V is terribly interesting, but I wouldn't block its progress just because Linus doesn't like it. So if folks are going to step up to make work, maintain it over time, etc then we should enable them to do that.
Is not really a block, but our current policy is to only enable ABIs that are
currently supported or planed by Linux. We used the same criteria to remove
ia64, even when people keep of-of-tree patch to keep it alive.  

Also, some time ago I installed some mipsr6 support, only to found out later 
that it was not even properly supported by the toolchain (and I am not even sure 
if/when it will be).

I think when Linus has it on linux-next, or similar maintainer tree to inclusion,
it would be less contentious to install the initial support.
diff mbox series

Patch

diff --git a/sysdeps/riscv/string-fzi.h b/sysdeps/riscv/string-fzi.h
index 613e5789e4..0eba3c8c6a 100644
--- a/sysdeps/riscv/string-fzi.h
+++ b/sysdeps/riscv/string-fzi.h
@@ -26,6 +26,73 @@ 
    instead of calling compiler auxiliary functions.  */
 # include <string-optype.h>
 
+# if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+static __always_inline unsigned int
+index_first (find_t c)
+{
+  if (sizeof (op_t) == 8)
+    {
+      if (c & 0x8000000000000000UL)
+        return 0;
+      if (c & 0x80000000000000UL)
+        return 1;
+      if (c & 0x800000000000UL)
+        return 2;
+      if (c & 0x8000000000UL)
+        return 3;
+      if (c & 0x80000000UL)
+        return 4;
+      if (c & 0x800000UL)
+        return 5;
+      if (c & 0x8000UL)
+        return 6;
+      return 7;
+    }
+  else
+    {
+      if (c & 0x80000000U)
+        return 0;
+      if (c & 0x800000U)
+        return 1;
+      if (c & 0x8000U)
+        return 2;
+      return 3;
+    }
+}
+
+static __always_inline unsigned int
+index_last (find_t c)
+{
+  if (sizeof (op_t) == 8)
+    {
+      if (c & 0x80UL)
+        return 7;
+      if (c & 0x8000UL)
+        return 6;
+      if (c & 0x800000UL)
+        return 5;
+      if (c & 0x80000000UL)
+        return 4;
+      if (c & 0x8000000000UL)
+        return 3;
+      if (c & 0x800000000000UL)
+        return 2;
+      if (c & 0x80000000000000UL)
+        return 1;
+      return 0;
+    }
+  else
+    {
+      if (c & 0x80U)
+        return 3;
+      if (c & 0x8000U)
+        return 2;
+      if (c & 0x800000U)
+        return 1;
+      return 0;
+    }
+}
+# else
 static __always_inline unsigned int
 index_first (find_t c)
 {
@@ -72,6 +139,7 @@  index_last (find_t c)
     return 1;
   return 0;
 }
+# endif /* __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__ */
 #endif
 
 #endif /* STRING_FZI_H */