Gedare Bloom commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5214#note_119955 This is a really interesting discussion and I appreciate the points both sides are making. As a preface to my perspective, we do not (cannot) have a uniform way of handling FP state within RTEMS because of ISA/platform-specific constraints on what is possible. So broad statements about FP state with respect to multi-threading are not possible. Any architecture-specific support for FP state is just that: ISA-specific. The Arm/aarch64 manuals are fairly clear in the sense that a function should not rely on the FPSCR upon function entry, and should not rely on the FPSCR if a function call is made to a public interface. (It's actually not clear that requires the public interface to be in a different translation unit, as you could call multiple public interfaces within the same translation unit.) An application that relies on FPSCR needs to read it first to know the initial state, and needs to read it again after any global function call is made. Although we save/restore the FP Register context, the issue of making the FPSCR/FPEXC part of the thread storage remains open in RTEMS. At best, it seems to only be an issue if using `fenv.h` which means `#pragma STDC FENV_ACCESS` is `ON` and supported by the compiler. So far I'm not aware that anyone actually requested that support. If there is a need for thread-level (rather than system-level) monitoring of exception state, this would seem to be a new feature that needs to be implemented in RTEMS with appropriate considerations to portability, design, and configuration. At present, I would leave this problem to the application to solve, because it sounds to me like the application is directly accessing ISA-specific features. This means that the application should itself treat `FPSCR` as caller-saved, and should save it and restore it around global function calls if preservation is desired. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5214#note_119955 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
