Share application objects and use LLD in CI

[Amaury Chamayou (achamayou)]

Summary

• Compile the shared application entry point once, and share the logging implementation between the default, COSE-only, and COSE-only/allow-dual-join binaries. Keep signing-mode overrides in the individual executable sources.
• Add OBJECT support to add_ccf_app, preserving warnings, sanitizers, hardening, clang-tidy and coverage instrumentation. Exclude object libraries from the coverage executable inventory.
• Select LLD explicitly in all five jobs in .github/workflows/ci.yml, install it for VMSS and pre-provisioned SNP runners, and retain existing downstream linker defaults.
• Include elapsed time in Ninja progress output and upload build/ninja.log with each job's logs for whole-build and per-edge comparisons.

Cold-build CI measurements

The target is cold full builds from an empty build directory, with no reused build outputs, not incremental builds or warm relinks. Each CI job creates a new build directory, configures it, and runs the complete Ninja build. Object sharing eliminates duplicate compilations within that clean build; it does not reuse objects from earlier runs. These measurements do not establish cold OS page-cache conditions.

This draft measures the combined full-build impact of object reuse and LLD. The comparison does not isolate their individual contributions. The existing test matrix and all three logging variants remain enabled. No compiler or build-artifact cache is introduced.

Compared the optimized CI run at ce863391d239544ee936068de356719bf8c8338c with the near-contemporaneous baseline CI run from changelog-only #8357. Both PRs share base b9c429bb3467242e60d3e19dbe947cd251463a30, and all measured jobs use Clang 18.1.8. Both runs' VMSS jobs use Standard_D16ads_v6, image version 52.0.0.

Complete Ninja elapsed times, excluding configuration, dependency installation and tests:

Full Ninja build	Before	After	Saving
Virtual A - clang-tidy	478.8 s	465.2 s	13.6 s / 2.8%
Virtual B	191.8 s	182.5 s	9.3 s / 4.8%
Virtual C	189.2 s	183.8 s	5.4 s / 2.8%
SNP Milan	422.8 s	411.9 s	11.0 s / 2.6%
SNP Genoa	317.7 s	298.3 s	19.3 s / 6.1%

The sum of the five build durations falls from 1600.3 s to 1541.7 s, saving 58.6 worker-seconds / 3.7%. The jobs run in parallel, so this is not 58.6 seconds off pipeline latency. Ninja's graph falls from 324 to 314 steps, consistent with eliminating ten compilations.

This is one matched comparison, not repeated controlled trials. Baseline elapsed times are measured from the logged + ninja invocation to the final completed Ninja edge; optimized times use Ninja's final elapsed-time status. Any repeat measurements should likewise start from empty build directories, not reuse a previous build.

Installation overhead currently erases the SNP build savings: the new Install LLD steps take 34 s on Milan and 28 s on Genoa. Including configuration, the build step falls from 426 s to 414 s on Milan and from 321 s to 301 s on Genoa, but adding LLD installation makes build-plus-install approximately 22 s and 8 s slower, respectively. Preinstalling LLD in the SNP runner images would avoid this per-job overhead; that image change is not included here. No reliable end-to-end pipeline speedup is established by this run.

The approximately 32% local saving below is object reuse alone on the application subgraph, not the combined cold full-build CI saving.

Local diagnostic measurements (not cold full builds)

These isolated experiments helped select changes to try in CI. They are not evidence of cold full-build savings; the complete CI builds above are the relevant measurement for that objective.

Native Linux filesystem under WSL, Clang 21.1.8, Debug, Ninja -j4:

• Object reuse alone: clean rebuilds of all seven application executables, with unchanged CCF libraries already built: 69.4 s -> 47.3 s, a 22.0 s / 31.8% reduction (two runs per version in alternating order).
• Application object compilations: 19 -> 9; total configured C/C++ compilations: 236 -> 226.
• These are not Azure Linux / Clang 18 CI timings.

Identical existing objects, one warmup and three measured relinks per linker, median seconds. These are warm relink-only measurements, not clean builds:

Binary	GNU BFD 2.46	LLD 21.1.8	mold 2.40.4
js_generic	3.614	0.587	0.603
logging	3.720	0.656	0.597
node_frontend_test	2.178	0.562	0.468

LLD is selected for the CI experiment; mold was only benchmarked locally.

Validation

• Built the affected applications and verified standalone logging variants against the installed SDK.
• Passed the C++ logging/COSE-only tests, COSE rolling-upgrade checks, and COSE recovery checks.
• Frontend unit tests passed with BFD, LLD and mold: 3 cases / 65 assertions each.
• Verified coverage, ASAN, clang-tidy and release-hardening configuration for shared objects.
• Sphinx --fail-on-warning, targeted CMake/Markdown/YAML formatting, release-note and ASCII checks passed.
• Verified the generated CCF link command includes -fuse-ld=lld, compiled and ran an LLD smoke binary, checked all five workflow jobs' provisioning/timing paths, and ran ShellCheck on the modified dependency installer.

A complete local default build/test suite was not run. All five CI build steps passed, but the optimized workflow is not green: SNP Milan's post-build programmability_and_jwt test failed while starting node 0 with SEV-SNP: attestation version 2 is less than the minimum supported version 3.