[all-commits] [llvm/llvm-project] 279a4d: -fsanitize=function: support C

[Fangrui Song via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 279a4d0d67c874e80c171666822f2fabdd6fa926
      https://github.com/llvm/llvm-project/commit/279a4d0d67c874e80c171666822f2fabdd6fa926
  Author: Fangrui Song <i at maskray.me>
  Date:   2023-05-22 (Mon, 22 May 2023)

  Changed paths:
    M clang/docs/ControlFlowIntegrity.rst
    M clang/docs/UndefinedBehaviorSanitizer.rst
    M clang/lib/CodeGen/CGExpr.cpp
    M clang/lib/CodeGen/CodeGenFunction.cpp
    A clang/test/CodeGen/ubsan-function.c
    A compiler-rt/test/ubsan/TestCases/TypeCheck/Function/c.c
    M compiler-rt/test/ubsan/TestCases/TypeCheck/Function/function.cpp
    M compiler-rt/test/ubsan/TestCases/TypeCheck/Function/lit.local.cfg.py

  Log Message:
  -----------
  -fsanitize=function: support C

With D148785, -fsanitize=function no longer uses C++ RTTI objects and therefore
can support C. The rationale for reporting errors is C11 6.5.2.2p9:

> If the function is defined with a type that is not compatible with the type (of the expression) pointed to by the expression that denotes the called function, the behavior is undefined.

The mangled types approach we use does not exactly match the C type
compatibility (see `f(callee1)` below).
This is probably fine as the rules are unlikely leveraged in practice. In
addition, the call is warned by -Wincompatible-function-pointer-types-strict.

```
void callee0(int (*a)[]) {}
void callee1(int (*a)[1]) {}
void f(void (*fp)(int (*)[])) { fp(0); }
int main() {
  int a[1];
  f(callee0);
  f(callee1); // compatible but flagged by -fsanitize=function, -fsanitize=kcfi, and -Wincompatible-function-pointer-types-strict
}
```

Skip indirect call sites of a function type without a prototype to avoid deal
with C11 6.5.2.2p6. -fsanitize=kcfi skips such calls as well.

Reviewed By: #sanitizers, vitalybuka

Differential Revision: https://reviews.llvm.org/D148827