Add external feature injection to GCC toolchain (like toolchains_llvm extra_known_features)

[RSingh1511]

Feature Request / Modification Description

score_cpp_policies defines sanitizer configurations as cc_feature targets (asan_ubsan_lsan_link, tsan_link). These can currently only be injected into the LLVM toolchain via extra_known_features (toolchains_llvm PR #678).

We need the same mechanism for the S-CORE GCC toolchain so both toolchains consume sanitizer features from a single source.

Proposed change:

Add extra_known_features (or equivalent) to score_bazel_cpp_toolchains
Replace the existing built-in asan/lsan/tsan/ubsan features by pulling them from score_cpp_policies

References:
eclipse-score/score_cpp_policies#1
eclipse-score/communication#182
bazel-contrib/toolchains_llvm#678

Expected Changes ot work products

• Requirements
• Architecture
• Safety Analysis
• Security Analysis
• Detailed Design
• Implementation and Testing
• all

Impact analysis

Build tooling change only. No impact on production code, safety analysis,
or security. Consuming modules (communication, logging) will use a single
sanitizer configuration instead of toolchain-specific ones.

Safety or Security relevance

• none
• Safety relevant
• Security relevant

Expected required ASIL classification

QM

Expected Implementation Version (Release)

1.0

[AlexanderLanin]

Hey, we discussed this request in the infrastructure community. Unfortunately no-one there was aware about score_cpp_policies. Can you provide some description of the repo / the concept and ideally a decision record for that repo?

[RSingh1511]

Hi @AlexanderLanin , thanks for raising this.

Origin: The need for a centralized C++ policies repo was identified in eclipse-score/logging#64, where a reviewer noted sanitizer configs were being duplicated per module. This follows the existing score_rust_policies pattern that is already accepted by the project.

What it provides: score_cpp_policies exposes reusable Bazel sanitizer configs (ASan, UBSan, LSan, TSan) as cc_feature targets (from rules_cc). Each module imports them with a single bazel_dep in MODULE.bazel, instead of maintaining its own copy.

Practical adoption example: eclipse-score/communication#182 shows exactly how a module integrates this — it uses extra_known_features in toolchains_llvm to inject the features and a single import line in .bazelrc. This is the reference integration.

Regarding the injection mechanism for score_bazel_cpp_toolchains (GCC toolchain) — that is precisely what this issue is tracking. We are aligned on the need and happy to collaborate on the design here.

Could you point us to the right template or process for a formal decision record if one is required?

[nradakovic]

The requested feature is added over PR:
#52

Before we merge this, please test it with score_cpp_policies. I executed some local tests but I need to know if this will work for you.
Keep in mind features are currently added at back of predefined feature list.

[AlexanderLanin]

@RSingh1511 can you please explain why cpp_policies is a separate repo and not included in bazel_cpp_toolchains? And some concrete examples of what we want to configure in sanitizers? Also personally I don't get the jump from "sanitizers" to "policies"?

[RSingh1511]

The requested feature is added over PR: #52

Before we merge this, please test it with score_cpp_policies. I executed some local tests but I need to know if this will work for you. Keep in mind features are currently added at back of predefined feature list.

Tested it via eclipse-score/communication#308 — extra_known_features injection works correctly on GCC. ASan and TSan canary tests pass with the GCC toolchain. One finding: score_cpp_policies link args include -fsanitize-link-c++-runtime which is Clang-only and causes a link error on GCC (not needed there, GCC handles runtime linking automatically via -fsanitize=). We worked around it with GCC-compatible local feature variants.
eclipse-score/communication#308

[RSingh1511]

@RSingh1511 can you please explain why cpp_policies is a separate repo and not included in bazel_cpp_toolchains? And some concrete examples of what we want to configure in sanitizers? Also personally I don't get the jump from "sanitizers" to "policies"?

This came up while adding sanitizers to the logging module (eclipse-score/logging#64), where we saw configs being duplicated per module. That's when we decided to create a common repo, following the score_rust_policies pattern. bazel_cpp_toolchains = how to build (compilers, sysroots), score_cpp_policies = what rules to build with (sanitizer flags, warning policies). Modules should adopt policies without pulling in a specific toolchain.

Today it provides cc_feature targets for ASan/UBSan/LSan/TSan, debug_symbols, runtime env templates, constraint targets (no_tsan, any_sanitizer), and flag infrastructure for select(). We also have a draft PR for Clang-specific policies (warnings, compile flags) that any consuming repo can adopt.

Re naming: "policies" because the scope goes beyond sanitizers — compiler warning policies, and potentially ASIL-level safety configs are planned. Same idea as score_rust_policies.