This is an archive of the discontinued LLVM Phabricator instance.

[SanitizerBinaryMetadata] Pretend compiler-generated loads/stores are atomic
ClosedPublic

Authored by melver on Jan 31 2023, 6:57 AM.

Details

Summary

Profiling and GCOV generate known data-racy loads/stores. Pretend they
are atomic so that analysis using PC-keyed metadata for atomics do not
report them as data races (which would look like false positives).

Diff Detail

Event Timeline

melver created this revision.Jan 31 2023, 6:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 31 2023, 6:57 AM
melver requested review of this revision.Jan 31 2023, 6:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 31 2023, 6:57 AM
dvyukov accepted this revision.Jan 31 2023, 8:12 AM

We also discussed that msan/asan shadow accesses need to be ignored.
MSan accesses can lead to false positives, ASan just to unnecessary checking.
It can also make sense to exclude accesses to global const objects.

This revision is now accepted and ready to land.Jan 31 2023, 8:12 AM

We also discussed that msan/asan shadow accesses need to be ignored.
MSan accesses can lead to false positives, ASan just to unnecessary checking.
It can also make sense to exclude accesses to global const objects.

Good points - will add in a future patch. Identifying sanitizer accesses is not obvious, probably need to add some more metadata in sanitizer passes.

TSan pass has these checks, probably can just copy-paste these:

  if (addrPointsToConstantData(Addr)) {
    // Addr points to some constant data -- it can not race with any writes.
    continue;
  }

if (isa<AllocaInst>(getUnderlyingObject(Addr)) &&
    !PointerMayBeCaptured(Addr, true, true)) {
  // The variable is addressable but not captured, so it cannot be
  // referenced from a different thread and participate in a data race
  // (see llvm/Analysis/CaptureTracking.h for details).
  NumOmittedNonCaptured++;
  continue;
}