Re: Disabling ssp directory

On Tue, Mar 3, 2026 at 12:31 AM John Scott <[email protected]> wrote:

> 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)
>

Somehow I didn't think about libssp. We do build that but newlib/libc/ssp
appears to replace it. In fact, the second commit for that directory
includes this:

    Note that this does require building gcc with --disable-libssp and
    gcc_cv_libc_provides_ssp=yes.

I think we need to disable that. It is easy enough with RTEMS since we have
the RTEMS Source Builder which is comparable to BSD ports. Recipes to build
all tool chains, other tools like dtc and qemu, and various libraries for
the target like snmp, protobuf, etc.

But all I wanted to disable when I started was __stack_chk_fail() function
from newlib/libc/ssp. We have our own implementation of that which ties
into the RTEMS Stack Checker and error reporting framework.

I was asking if I should I add ifndef __rtems__ in stack_protector.c to
disable it or add a generic -D like HAVE_MALLOC. Looking closer at the
file, it already has ifdefs on rtems and cygwin. That leans me to just
adjusting that to disable it for rtems.

You have more than answered the question.

Thanks. You sent me in a direction I also needed to explore.

--joel