As a 3rd-year B.Tech student in Communication and Computer Engineering at LNMIIT Jaipur, my Google Summer of Code (GSoC) 2026 journey with the RTEMS Project has officially reached the finish line. RTEMS is a Real-Time Operating System (RTOS) that powers safety-critical embedded systems like spacecraft, medical devices, and automotive controllers.

Because RTEMS uses Newlib as its standard C library, which lacks the C11 Annex K standard, RTEMS developers have historically had no standard way to use bounds-checked string and memory functions. My project bridged this gap by packaging the MIT-licensed safeclib library into the RTEMS Source Builder (RSB), giving embedded developers secure alternatives like memcpy_s and sprintf_s.

Part 1: The Executive Summary (GSoC Submission)

• Project Goal: Bring C11 Annex K bounds-checking functions to the RTEMS toolchain via safeclib integration.
• What I Did: I engineered the cross-compilation recipe for safeclib within the RSB, solved configure-time linker failures on bare-metal targets, wrapped the test suite in RTEMS standard tasks, and successfully built multilib support.
• Current State: The core RSB integration for per-BSP builds is complete and in active upstream review.

  What Code Got Merged/Submitted:

• Core RSB Recipe Integration: RSB Merge Request !287
  • Description: RSB cross-compilation recipe for safeclib, refined with modular configs and base64 hashes based on maintainer feedback.
• Upstream Test Suite Submission: Safeclib Pull Request #172
  • Description: Submitted the pure C Annex K edge-case test suite (test_baremetal_edges.c) upstream.
• Upstream Feature Request: Safeclib Issue #171
  • Description: Opened an upstream issue requesting a proper --disable-tests configuration flag.
• RTEMS Workaround Tracking: RTEMS Tools Work Item #209
  • Description: Tracked the temporary sed Makefile workaround until the upstream issue is resolved.
• POSIX Compliance Tracking: RTEMS Work Item #156
  • Description: Mapped and documented C11 Annex K functions into the RTEMS compliance master spreadsheet.
• What’s Left To Do: Once MR !287 establishes the baseline, I will push the multilib code upstream, update the RTEMS 7 Release Notes, and publish a Developer Wiki Guide.

Part 2: The Deep Technical Dive

For developers and engineers curious about the intricacies of cross-compiling standard libraries for bare-metal targets, here is a breakdown of the core technical challenges I solved this summer.

1. Upstream Contributions (Pre-GSoC)

Before the GSoC coding period even began, I analyzed the safeclib source code and identified several portability blockers. I worked directly with the upstream maintainer (Reini Urban) to get several fixes merged upstream:

• PR #152 & #153: Fixed missing labels and -Wunused-variable compiler errors that caused -Werror failures on RTEMS bare-metal targets.
• The isinfl() Portability Issue: safeclib relies on isinfl(), which Newlib only provides under specific Cygwin macros. I proposed a tiered fallback strategy (PR #154) which led to the upstream implementation of a robust isinf fallback.

2. The Linker & Cross-Compilation Puzzle

When building libraries with autotools for bare-metal systems, configure-time link tests routinely fail because there is no standard OS environment (like a default main() or POSIX I/O).

Initially, I attempted to force the linker to succeed by injecting a pre-compiled rtems_config.o object file. However, after architectural discussions with my mentors, I implemented the correct, robust solution: utilizing pkg-config to fetch BSP-specific flags and linking against librtemsdefaultconfig.a. This allowed the configure script to correctly evaluate the environment without artificial scaffolding.

build: safeclib-3.9.1-x86_64-linux-gnu-1
install: safeclib-3.9.1-x86_64-linux-gnu-1
cleaning: safeclib-3.9.1-x86_64-linux-gnu-1
Build Set: Time 0:02:14.453210
Build Set: Time 0:02:28.109432
Packages: 1
Sizes: 1.2MB
Installed: 1
==> build successfully: 7/devel/safeclib

3. Bare-Metal Test Scaffolding

safeclib ships with approximately 126 tests. On Linux, these just run. On RTEMS, a bare-metal environment has no concept of a standalone executable starting from main().

I had to manually wrap the test suite within minimal RTEMS applications—specifically, injecting an Init task and a configuration table into each test. I cross-compiled these for sparc-rtems7 and ran them under QEMU SPARC emulation, strictly documenting the results (PASS, FAIL, or SKIP for tests requiring unavailable resources like signals).

*** BEGIN OF TEST SAFECLIB MEMCPY_S ***
*** TEST VERSION: 7.0.0.db2a265691d1e4347715fba394f4ed81eb
*** TEST STATE: EXPECTED_PASS
*** TEST BUILD: RTEMS_POSIX_API
*** TEST TOOLS: 13.2.0 20230727 (RTEMS 7, RSB d5d9d1a4470134ea9292514c)

Testing memcpy_s()...
PASS: memcpy_s(dest, dmax, src, smax) with valid inputs
PASS: memcpy_s(dest, dmax, NULL, smax) returns ESNULLP
PASS: memcpy_s(NULL, dmax, src, smax) returns ESNULLP
PASS: memcpy_s(dest, 0, src, smax) returns ESZEROL
PASS: memcpy_s(dest, dmax, src, smax) where dmax < smax returns ESLEMAX

All 24 test cases passed successfully.

*** END OF TEST SAFECLIB MEMCPY_S ***

4. Above & Beyond: The Multilib Loop Challenge

My original proposal listed “multilib integration” as a future improvement. I tackled it early. True multilib support means building the library for every supported ABI variant of an architecture simultaneously.

To achieve this, I wrote a custom shell loop in the %build phase of the RSB recipe that parses gcc --print-multi-lib. The hardest bug here involved nested architecture directories (like leon3/gr712rc). Standard relative pathing to ../configure crashed because the depth was variable. I engineered a fix by caching the absolute root path:

# Caching the absolute top-level directory to handle nested multilib variants
build_top=$(pwd)

# Iterate through all architecture variants
for i in $(gcc --print-multi-lib); do
  variant=$(echo $i | sed -e 's/;.*//')
  mkdir -p $variant
  cd $variant

  # Inject the absolute path to solve nested directory crashes
  ${build_top}/configure \
    --host=%{_host} \
    --disable-shared --enable-static \
    --disable-extensions \
    CFLAGS="${BSP_CFLAGS}"

  make
  cd ${build_top}
done

This loop dynamically adapts to the depth of the variant’s folder, ensuring a stable multilib build across the entire RTEMS ecosystem.

Final Thoughts & Acknowledgments

Working on RTEMS has fundamentally shifted how I view systems programming and OS architecture. I want to extend a massive thank you to my mentors, Joel Sherrill and Wayne Thornton, for their incredible guidance, architectural insights, and code reviews this summer. I also want to thank Reini Urban for his responsiveness upstream.

GSoC may be ending, but my work with RTEMS is not. I look forward to continuing as a maintainer for the safeclib integration and tackling more toolchain challenges in the future.

What sounded like a straightforward porting task quickly evolved into a deep dive into cross-compilation quirks, dynamic build configurations, and debugging strict-alignment hardware exceptions on the SPARC architecture.

In this post, I will break down exactly how I patched the library, conquered the RSB, and validated the test suite in the SPARC simulator, documenting every pitfall so future developers can navigate them easily.

Challenge 1: Architecture Independence (The Patch)

The first major hurdle was the “multilib” problem. The safeclib source code relied heavily on hardcoded compiler checks (like sizeof(uint32_t)) that inherently break when cross-compiling for different architectures.

The Fix: I created a C patch to rip out those hardcoded checks and replace them with dynamic GCC macros (like __SIZEOF_POINTER__). This ensures the library is truly architecture-independent and adapts at compile-time to whatever target RTEMS requires.

Challenge 2: Taming the Build System (The RSB Recipe)

Writing the RSB .cfg recipe required bypassing several unique build system bugs and bare-metal traps:

1. The Git Extraction Bug: The RSB initially refused to clone the source properly. The Fix: I forced the RSB to unpack the code by explicitly appending ?checkout=master?pull=1 to the source URL.
2. The Symlink Bug: RSB had a hidden bug where it failed to define the source directory, breaking the build pipeline. The Fix: I bypassed this by manually injecting source_dir_safeclib="rtems-safeclib" into the %prep phase.
3. The Bare-Metal Compiler Trap: safeclib aggressively tried to enforce Linux-style Stack Smashing Protectors (ssp.h) and strict GCC warnings. The Fix: I injected custom bare-metal override flags (-U_FORTIFY_SOURCE -fno-stack-protector -Wno-error) into the CFLAGS during the ./configure step.

Challenge 3: Dynamic Multi-Architecture Support & Linker Errors

To make the recipe robust for the RTEMS ecosystem, it needed to support cross-architecture builds out of the box (MR !269).

1. Dynamic pkg-config: I replaced the hardcoded rtems-bsps placeholder with dynamic host/bsp extraction (%{_host}-$(basename %{with_rtems_bsp})) during the %build phase. This allows pkg-config to correctly extract compilation flags for any target architecture (SPARC, RISC-V, etc.).
2. Bypassing the Syslog Linker Error: On bare-metal targets, linking the performance tests failed entirely due to an undefined reference to syslog—a utility that simply doesn’t exist on these lightweight embedded targets. The Fix: I used sed to strip the tests directory from the generated Makefile targets. This prevented the broken test suite from interrupting the build while ensuring the core library, headers, and .pc files installed correctly.

The First Milestone: Minimal Proof of Execution

With the library successfully building, the initial test was to link it against a basic bare-metal RTEMS application to verify the hooks.

I wrote a minimal RTEMS initialization task that invokes the strcpy_s (secure string copy) function from my newly compiled static library. Running it in the SPARC Instruction Simulator (sparc-rtems7-sis) yielded a clean execution:

The Final Boss: Full Test Suite Validation

With basic execution proven, the final step was running the entire safeclib test suite on the simulator. This is where the real bare-metal debugging began.

Initially, the test suite threw catastrophic OS-level crashes. I had to debug and apply two critical OS-level fixes to my RTEMS initialization task:

1. FPU Exceptions (Code 38): The simulator was crashing due to illegal floating-point unit usage. The Fix: I injected the RTEMS_FLOATING_POINT attribute into the Init task.
2. File Descriptor Exhaustion: The library’s fopen tests were crashing the OS because RTEMS defaults to a highly restrictive file descriptor limit. The Fix: I bumped CONFIGURE_MAXIMUM_FILE_DESCRIPTORS up to 32.

The Result: 116 PASS and Hardware Bug Hunting

Once the OS configurations were patched, the test suite results immediately jumped to 116 PASS.

More importantly, clearing away the OS crashes isolated the remaining 15 Fails and 6 Timeouts (in functions like test_memcpy32_s and test_mbstowcs_s). As suspected, these are not OS errors, but genuine SPARC strict-alignment data access exceptions (Trap 9s) and infinite loops.

Standard x86 desktop processors often hide these memory alignment flaws, proving exactly why validating this library on strict bare-metal architectures like SPARC is so critical. I am currently documenting these isolated hardware traps to file as upstream bug reports to the safeclib maintainers.

With the library ported, dynamically compiling across architectures in the RSB, and the SPARC validation complete, my midterm deliverables are officially wrapped. Next up: building the riscv-rtems7-gcc toolchain and seeing how RISC-V handles these exact same memory alignment tests!

When porting a standard C library to a bare-metal embedded real-time operating system (RTOS) like RTEMS, you quickly learn that standard build tools make a lot of assumptions about your environment. Specifically, tools like Autoconf expect a standard POSIX-compliant OS to be sitting underneath them.

For my Google Summer of Code project, I am porting the safeclib library to RTEMS. Recently, I ran into a classic cross-compilation trap involving autoconf probes, linker errors, and the temptation to just “brute-force” the build.

Here is how I fell into the trap, and more importantly, the architectural pivot required to do it the “RTEMS way.”

The “Blindfold” Method: Ignoring Unresolved Symbols

Initially, to get the autotools ./configure script to pass its generic C compiler dummy test without failing on missing RTEMS scaffolding, I bypassed the linker errors using a brute-force flag:

LDFLAGS=”-Wl,–unresolved-symbols=ignore-all”

It worked… sort of. The build moved forward, but as my mentor pointed out, ignoring undefined symbols on an autoconf probe is a terrible idea. It effectively puts a blindfold on the compiler. It allows the autoconf probes to falsely report features as “present” (like fork() or getpid()) even when they are entirely missing from the bare-metal environment. This guarantees silent crashes down the line.

The Pivot: Linking the Board Support Package (BSP)

To fix this, I dropped the ignore-all flag and decided to point the configuration script directly to the installed SPARC RTEMS7 BSP (erc32). This forces the script to look at the actual symbols available in the embedded environment.

export RTEMS_ROOT=$HOME/development/rtems/7/sparc-rtems7/erc32

./configure
–host=sparc-rtems7
–prefix=$RTEMS_ROOT
–enable-static
–disable-shared
CC=”sparc-rtems7-gcc -qrtems -B$RTEMS_ROOT/lib/”
CPPFLAGS=”-I$RTEMS_ROOT/include”

Unveiling the True Linker Errors

Once the blindfold was off, the script failed immediately on the very first probe: checking whether the C compiler works... no.

Digging into the config.log, I found the exact culprit. The RTEMS compiler was refusing to link the autoconf conftest.c dummy file, throwing these undefined references:

• _ISR_Stack_size
• _ISR_Stack_area_begin
• _Scheduler_Table
• _Thread_Information

The Aha Moment: These are not standard C library functions; they are RTEMS kernel configuration symbols! In RTEMS, an application requires a configuration block (typically via <rtems/confdefs.h>) to allocate memory for the scheduler, threads, and interrupts. Because the autotools dummy script is just an empty int main() without this header, the RTEMS linker panicked.

The Path Forward

In cross-compilation, there are generally two professional ways to handle autoconf probes failing on bare-metal:

1. Use a Dummy Config Library: RTEMS provides librtemsdefaultconfig.a, which defines stubs for these exact configuration macros to satisfy the linker during tests.
2. Hard-code the Variables: Bypass the executable tests entirely and manually inject a config.site file that tells the build system exactly which OS features are (and aren’t) available.

I am currently discussing the best architectural approach with my mentors to integrate this cleanly into the RTEMS Source Builder (RSB).

If you want to follow along with the code, I am pushing all my Work-In-Progress (including some MSVC test stub adjustments) to my personal RTEMS GitLab fork here: https://gitlab.rtems.org/Yash/rtems-safeclib

For those who might not know, RTEMS is a real-time operating system that flies on ESA and NASA spacecraft, runs medical devices, and powers automotive controllers.

The Problem

RTEMS currently uses Newlib as its C library. However, Newlib does not implement the standard C11 Annex K bounds-checking interfaces. This means RTEMS developers writing code for safety-critical systems have no standardized way to use bounds-checked memory and string functions (like strcpy_s or memset_s). They usually have to rely on the unsafe originals or write their own wrappers.

My Project

My mission for the summer is to package safeclib—a library that implements all 45 Annex K functions—through the RTEMS Source Builder (RSB). By the end of August, developers will be able to easily build and link these safe functions for any RTEMS Board Support Package (BSP) just by adding -lsafec.

The pre-coding community bonding period is officially wrapping up today. I’ve spent the last couple of weeks finalizing the RSB recipe design with my mentors, Joel Sherrill and Gedare Bloom, and verifying upstream compatibility.

Coding officially begins tomorrow! My immediate next step is to draft the RSB .cfg and .bset skeleton and get the RTEMS Init task scaffolding running under QEMU SPARC to test the library on bare metal.

I’ll be posting weekly technical updates right here. Stay tuned!