RTEMS Source Builder | RISC-V/GCC 15: Newlib is built allowing unaligned accesses (#144)

[Kinsey Moore (@opticron)]

Kinsey Moore commented: https://gitlab.rtems.org/rtems/tools/rtems-source-builder/-/issues/144#note_135804


While the fix mentioned above is the correct fix for NOEL-V, you're right that it would affect all other RISC-V BSPs and that should be avoided. This means that possible solutions are:

* Add a multilib variant that provides supporting libraries with strict alignment
* Add support to RTEMS RISC-V CPU port for RTEMS_EXCEPTION_EXTENSIONS and use that to emulate unaligned accesses
* Force all multilibs to use `-mstrict-align`

In the case of the first solution, we need a way to delineate strictly aligned multilibs from others which can be configured in RTEMS so that the correct multilib is selected. This also adds to the already wide variety of multilibs available for RISC-V which increases the time to compile the toolchain. We may want to reconsider exactly which multilibs need to be represented.

The second solution has drawbacks as well since strictly aligned code will be significantly more efficient than emulated support, especially for large memcmp() or memcpy() calls. If RTEMS were to ever run in something other than M-mode, this solution would be required to operate alongside other possible solutions.

As for the third solution, there is anecdotal evidence around the internet that, generally, M-mode code should not use unaligned accesses at all and that, generally, unaligned accesses are slower than aligned accesses.

Some questions to answer:
* Is there an easy way to know whether a RISC-V CPU supports misaligned accesses beyond trying it to see if it generates a trap?
* How do we differentiate between strict/non-strict multilibs?
* Should we switch all RISC-V multilibs/BSPs to strict alignment?

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/tools/rtems-source-builder/-/issues/144#note_135804
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20251107/68cefddb/attachment.htm>