Re: Disabling ssp directory

John Scott <[email protected]> Tue, 03 Mar 2026 06:31:01 +0000
Newsgroups	gmane.comp.lib.newlib
Message-ID	<[email protected]>
Joel Sherrill wrote:
> RTEMS has its own version of the stack protection functions. 
> To avoid potential conflicts, I'd like to disable ssp/ from the build.
> There is currently no conditional mechanism to disable it.
> Would adding another newlib_cflags like HAVE_SSP be ok?
> It seems like the easiest solution and is aligns with what has been done in other cases where the target provides a function also in newlib

I'm still new to this sort of stuff and mostly only lurk on these lists, so use healthy skepticism. But I think what you ought to do is have the top-level configure.ac (the one shared among Binutils, GCC, GDB, and friends) specify that ssp/ is a directory *not* to be built for RTEMS target triples.

For example, GCC documents the --disable-libssp command-line option at https://gcc.gnu.org/install/configure.html#:~:text=disable-libssp
> Specify that the run-time libraries for stack smashing protection should not be built or linked against. On many targets library support is provided by the C library instead.
For an example where I've used this, in building the 802.11n NIC firmware at https://github.com/qca/open-ath9k-htc-firmware we need a custom xtensa-elf freestanding toolchain; we don't even use Newlib or any conventional ISO C standard library or RTOS underpinnings. Instead the folks at Qualcomm Atheros and Tensilica provided their hardware abstraction layer which sidesteps all of that. It's my understanding that libssp hardens suspect functions in the C library by effectively wrapping them. Because our target doesn't even have the most conventional of functions, the GCC build fails unless we pass --disable-libssp, because we're in the unusual situation where we don't even have headers like <string.h>, we don't need them, and we're not going to have an ISO C library now or even later. Even if we don't have Newlib in the source tree and are building plain GCC, the top-level configure will try to build libssp anyway and fail.
The libssp subdirectory is, of course, shipped with GCC itself, so for this unusual circumstance (most folks building an xtensa-none-elf toolchain will have a C library of some kind, eventually, but not us!), we pass --disable-libssp. It is reasonable for GCC to assume otherwise that we have an ISO C library, or at least have the headers for the library to follow.
(By the way, I'm aware that specifically building a "stage one GCC" with the designated makefile target will probably sidestep these issues for our case. That's on my to-do list, after I wrap my head around how things are somehow working now 😉)

So disabling the build of libssp is already possible manually, but I take it you want this to be more automatic: the build system should just know that RTEMS is special and will never want these functions.
At (current) line 639 in the top-level configure.ac (again, the one shared with Binutils/GCC/GDB/Newlib/XYZ) at https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=configure.ac;hb=HEAD#l639 we find that some systems already have carve-outs so they don't get libssp built:
# Disable libssp for some systems.
case "${target}" in
  avr-*-*)
    # No hosted I/O support.
    noconfigdirs="$noconfigdirs target-libssp"
    ;;
  bpf-*-*)
    noconfigdirs="$noconfigdirs target-libssp"
    ;;
  powerpc-*-aix* | rs6000-*-aix*)
    noconfigdirs="$noconfigdirs target-libssp"
    ;;
  pru-*-*)
    # No hosted I/O support.
    noconfigdirs="$noconfigdirs target-libssp"
    ;;
  rl78-*-*)
    # libssp uses a misaligned load to trigger a fault, but the RL78
    # doesn't fault for those - instead, it gives a build-time error
    # for explicit misaligned loads.
    noconfigdirs="$noconfigdirs target-libssp"
    ;;
  visium-*-*)
    # No hosted I/O support.
    noconfigdirs="$noconfigdirs target-libssp"
    ;;
esac

So it seems like RTEMS deserves to be a part of this group, with something like this perhaps?
+	rtems-*-*)
+		# RTEMS provides its own functionality similar to libssp.
+		noconfigdirs="$noconfigdirs target-libssp"
+	;;

My understanding is the GCC git repo is the canonical location for this configure.ac, so patches should be sent there and it can be syndicated to the sibling projects as needed.

Note: I don't (yet) use RTEMS, and I'm not in a position to test this. But hopefully I've steered you towards a nice tree to bark up (woof)
signature.asc (application/pgp-signature, 411 B)