Lucian Silistru commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/277#note_122903 What is in newlib's version that you think is an improvement? > Nothing really, just the location, maybe. It's why I was wondering if it > could be rtems-ized more (stubs, think I saw some used for RTEMS > implementations needed by newlib? but not sure stack checkers fit the > requirements) Other than that this is the best option. I already implemented an RTEMS-like override at app level and between libssp in gcc (btw, some rtems-tools app wants libssp to exist to validate gcc) and newlib stack_protector, it was messy. gcc libssp has a couple more functions implemented buuut, I have no idea where they are used, haven't missed them since disabling libssp. The random in newlib is slightly useless (runs too early in RTEMS for any randomness from that arc function). Sysinit is too late. You need a source of random-ish and that's board/cpu dependant. And like I said, there's the TLS drag-ins by the newlib implementation (call to write) that break the expected stack sizes in a handful of tests. By the way, there seems to be some __SSP defines enabled by -fstack-protector. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/277#note_122903 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
