This is an archive of the discontinued LLVM Phabricator instance.

[msan][CodeGen] Set noundef for C return value
ClosedPublic

Authored by vitalybuka on Dec 4 2022, 11:27 PM.

Details

Summary

Msan needs noundef consistency between interface and implementation. If
we call C++ from C we can have noundef on C++ side, and no noundef on
caller C side, noundef implementation will not set TLS for return value,
no noundef caller will expect it. Then we have false reports in msan.

The workaround could be set TLS to zero even for noundef return values.
However if we do that always it will increase binary size by about 10%.
If we do that selectively we need to handle "address is taken"
functions, any non local functions, and probably all function which have
musttail callers. Which is still a lot.

The existing implementation of HasStrictReturn refers to C standard as
the reason not enforcing noundef. I believe it applies only to the case
when return statement is omitted. Testing on Google codebase I never see
such cases, however I've see tens of cases where C code returns actual
uninitialized variables, but we ignore that it because of "omitted
return" case.

So this patch will:

  1. fix false-positives with TLS missmatch.
  2. detect bugs returning uninitialized variables for C as well.
  3. report "omitted return" cases stricter than C, which is already a warning and very likely a bug in a code anyway.

Diff Detail

Event Timeline

vitalybuka created this revision.Dec 4 2022, 11:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 4 2022, 11:27 PM
vitalybuka requested review of this revision.Dec 4 2022, 11:27 PM
Herald added a project: Restricted Project. · View Herald TranscriptDec 4 2022, 11:27 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
kda edited the summary of this revision. (Show Details)Dec 5 2022, 1:19 PM
kda added a comment.Dec 5 2022, 1:24 PM

Is there a risk of this being too strict for standard C?

Should there be a test case for our specific problem? (C calling C++)

Is there a risk of this being too strict for standard C?

Should there be a test case for our specific problem? (C calling C++)

Probably not. It's cross module mismatch. To reproduce we need two module and one of them will do about the same as the current msan-param-retval.c.

kda accepted this revision.Dec 5 2022, 2:36 PM

LGTM

This revision is now accepted and ready to land.Dec 5 2022, 2:36 PM
aeubanks added inline comments.
clang/lib/CodeGen/CGCall.cpp
1827–1828

should this be dropped? and maybe also move up SanitizerKind::Return?

remove redundant check

vitalybuka marked an inline comment as done.Dec 5 2022, 10:58 PM
vitalybuka added inline comments.
clang/lib/CodeGen/CGCall.cpp
1827–1828

Documentation for SanitizerKind::Return explicitly states that it's C++ check.
So I will leave it as is.

This revision was landed with ongoing or failed builds.Dec 5 2022, 10:58 PM
This revision was automatically updated to reflect the committed changes.
vitalybuka marked an inline comment as done.