GCC linking fails due to incorrect `libgcc` link order

Description

We are encountering linker failures on AArch64 builds caused by unresolved outlined atomic helper symbols such as:

__aarch64_ldadd4_acq_rel
__aarch64_cas2_acq_rel
__aarch64_swp4_acq_rel

These symbols are emitted by GCC when compiling with outlined atomics (default on AArch64) and are expected to be resolved from libgcc.

We verified that the toolchain-provided libgcc.a does contain these symbols, so the issue is not missing runtime support.

Root Cause

Root Cause

The problem appears to be link order / link grouping when using static libraries:

• The link uses a large number of static archives (-Wl,-Bstatic)
• -nodefaultlibs is enabled, so runtime libraries must be added explicitly
• libgcc is either:
  • added too early, or
  • not grouped with dependent static libraries

Because of this, the linker does not pull in the required objects from libgcc.a when resolving references originating from later static libraries.

This is a standard static linking behavior: archives are only searched once, left-to-right.

Proposed Fix

Ensure that libgcc (and related runtime libs) are linked after all static libraries that may reference them.
Two valid approaches:

Option 1 — Late linkage
Add at the end of the link command:

-lgcc
-lgcc_eh

Option 2 — Link group (more robust for large static graphs)

-Wl,--start-group
<all static libraries>
-lgcc
-lgcc_eh
-Wl,--end-group

Expected Changes ot work products

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

Impact analysis

NA

Safety or Security relevance

• none
• Safety relevant
• Security relevant

Expected required ASIL classification

QM

Expected Implementation Version (Release)

1.0