[clang] Thread Safety Analysis: Support warning on taking address of guarded variables (PR #123063)

Aaron Puchert via cfe-commits cfe-commits at lists.llvm.org
Tue Feb 11 15:04:14 PST 2025


aaronpuchert wrote:

> The equivalent of passing a `pt_guarded_by` variable by value doesn't seem to warn.

This inconsistency is probably my largest concern. If you have
```c
int x GUARDED_BY(mu);
int *p PT_GUARDED_BY(mu);
```
then `&x` should basically behave like `p`, and `x` like `*p`. But with the current implementation, that cannot be the case, because `p` is just a no-op.

That's why I think we should rather check function arguments, and warn on passing (1) the address of a guarded variable, (2) a pointee-guarded variable. There is already functionality that makes sure (1) and (2) work together: `checkAccess` and `checkPtAccess` call each other when necessary. This doesn't seem to handle unary `&` at the moment, but I suppose this would be easy to add. The check for passing arguments itself is in `examineArguments`. We currently only check reference type arguments:
```c++
    if (Qt->isReferenceType())
      checkAccess(*Arg, AK_Read, POK_PassByRef);
```
Here we might simply add a branch for pointer types with the appropriate `POK` that you already introduced (though we might need to rename it slightly).

This still doesn't cover local pointer variables, but here I guess we need a better understanding of the patterns and how much alias analysis we'd need to unravel them. Local pointer variables as obfuscation device are hopefully not common, so there is likely some more complex logic that would be intractable for us anyway. So I'd be curious to see some interesting examples.

https://github.com/llvm/llvm-project/pull/123063


More information about the cfe-commits mailing list