Skip to content

fix(global-read-before-write): identify a global across files as the linker does - #197

Merged
SizzleUnrlsd merged 2 commits into
mainfrom
166-static-global-cross-tu
Oct 9, 2026
Merged

SizzleUnrlsd merged 2 commits into
mainfrom
166-static-global-cross-tu

Conversation

@SizzleUnrlsd

@SizzleUnrlsd SizzleUnrlsd commented Oct 8, 2026 •

Copy link
Copy Markdown
Contributor

Fixes #166

Problem

The cross-TU summary of GlobalReadBeforeWrite keyed each global by its raw IR name, whatever its linkage. Two static globals with the same name in two files, or a static and an external one, shared one entry: a write to one counted as a write to the other. Reproduced on main faf1050:

Files read_table (reads the static table of a.c)
a.c 0.55
a.c b.c (static table written in b.c) 0.50 + "at least one write ... in another analyzed function/TU"
a.c ext_table.c (external table written) 0.50 + same note

Fix

A summaryKey function now gives the key at the 3 places that read or write the index:

LLVM module identifiers are not unique here (every module is cached_ir or in_memory_ll), so the key uses the address of the llvm::Module. The index is only built in shared loading, from the modules that are then analyzed, so the address is stable for the lifetime of the index. The header documents the key.

Tests

  • New check check_global_read_before_write_identity_across_files covers both collisions, a static global written in another function of its own file, and an external global written in another file.
  • RED on the main binary: the 2 collisions fail, the 2 guards pass. GREEN: 4/4.
  • Mutants caught: a static keyed by its name alone, and static globals left out of the index.
  • CI-like suite on Linux x86_64: 2385/2385, unit tests included.

Before / after (main faf1050 vs this branch, Linux x86_64)

  • Fixtures, default and z3: 846 runs, 0 differ, 1287 = 1287 diagnostics.
  • Self-analysis, 4 chunks: 71 = 71 diagnostics, 0 differ.

Limits

  • Fixtures are analyzed one file at a time, and the index only exists with at least two files. The self-analysis has no GlobalReadBeforeWrite result. The two comparisons show no regression elsewhere; the new check is what covers the fix.
  • linkerSymbolName instead of the raw name only matters for a renamed symbol (__asm__). No case covers that here.

Code scanning

CI is green on 4c64dd4: 13 checks pass, the release attach step is skipped.

  • 66 open alerts on the merge ref, the same numbers as on main: none new, none gone.
  • No github-advanced-security comment on this PR. No new coretrace-concurrency-analyzer alert.
  • This matches the local self-analysis before/after: 71 = 71 results, 0 differ.

… linker does

Two static globals with the same name in two files, or a static and an
external one, share one cross-TU entry: a write to one counts as a write
to the other (#166). Cover both collisions, a static global written in
another function of its own file, and an external global written in
another file.
…linker does

The cross-TU summary keyed each global by its raw IR name, whatever its
linkage. Two static globals with the same name in two files, or a static
and an external one, shared one entry, so a write to one counted as a
write to the other.

Key an external global by its linker symbol, as the cross-TU function
facts do (#157). Key a static global by its module too: it stays in the
index, so a write in another function of its own file still counts, but
no other file finds it.

Fixes #166
@SizzleUnrlsd SizzleUnrlsd added the bug Something isn't working label Oct 8, 2026
@SizzleUnrlsd SizzleUnrlsd self-assigned this Oct 8, 2026
@SizzleUnrlsd
SizzleUnrlsd merged commit b0982b2 into main Oct 9, 2026
14 checks passed
@SizzleUnrlsd
SizzleUnrlsd deleted the 166-static-global-cross-tu branch October 9, 2026 02:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

GlobalReadBeforeWrite: static globals with the same name in two files share one cross-TU entry

1 participant