melver wrote:
As additional motivation - quote from a kernel maintainer:
> But I think we should get the infrastructure in once your reentrancy
> support has landed in a release, because with that we can start
> annotation some code and show uses, while also helping to driver more
> requirements
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From b264872c3f28f6cf172b0123087adda9d53dc1b9 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
melver wrote:
Gentle ping - PTAL.
Many thanks!
https://github.com/llvm/llvm-project/pull/137133
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
melver wrote:
Thanks for the feedback. Addressed comments as best as I could.
Most notable changes:
- Also warns properly for loops with mismatching reentrancy depth.
- Devirtualized new helpers.
- Require ordering `reentrant_capability` after `capability`.
- Stylistic improvements.
PTAL.
http
@@ -235,6 +266,20 @@ class FactSet {
return false;
}
+ std::optional replaceLock(FactManager &FM, iterator It,
+std::unique_ptr Entry) {
+if (It == end())
+ return std::nullopt;
+FactID F = FM.newFact(std::move(Entry));
+
Author: Marco Elver
Date: 2025-05-09T20:14:30+02:00
New Revision: 49c22e3ee147326668aa0b2097f857d0b0c2a81e
URL:
https://github.com/llvm/llvm-project/commit/49c22e3ee147326668aa0b2097f857d0b0c2a81e
DIFF:
https://github.com/llvm/llvm-project/commit/49c22e3ee147326668aa0b2097f857d0b0c2a81e.diff
L
@@ -271,26 +272,34 @@ class CFGWalker {
// translateAttrExpr needs it, but that should be moved too.
class CapabilityExpr {
private:
- /// The capability expression and whether it's negated.
- llvm::PointerIntPair CapExpr;
+ static constexpr unsigned FlagNegative = 1u << 0;
@@ -1011,6 +979,30 @@ void SExprBuilder::exitCFG(const CFGBlock *Last) {
IncompleteArgs.clear();
}
+static CapabilityExpr makeCapabilityExpr(const til::SExpr *E, QualType VDT,
+ bool Neg) {
+ // We need to look at the declaration of t
@@ -271,26 +271,32 @@ class CFGWalker {
// translateAttrExpr needs it, but that should be moved too.
class CapabilityExpr {
private:
- /// The capability expression and whether it's negated.
- llvm::PointerIntPair CapExpr;
+ /// The capability expression and flags.
+ llvm::
@@ -4048,6 +4048,9 @@ def warn_thread_attribute_not_on_scoped_lockable_param :
Warning<
"%0 attribute applies to function parameters only if their type is a "
"reference to a 'scoped_lockable'-annotated type">,
InGroup, DefaultIgnore;
+def warn_reentrant_capability_witho
@@ -1078,22 +1091,65 @@ void
ModuleSanitizerCoverage::InjectCoverageAtBlock(Function &F, BasicBlock &BB,
Store->setNoSanitizeMetadata();
}
if (Options.StackDepth && IsEntryBB && !IsLeafFunc) {
-// Check stack depth. If it's the deepest so far, record it.
Modu
@@ -1078,22 +1091,65 @@ void
ModuleSanitizerCoverage::InjectCoverageAtBlock(Function &F, BasicBlock &BB,
Store->setNoSanitizeMetadata();
}
if (Options.StackDepth && IsEntryBB && !IsLeafFunc) {
-// Check stack depth. If it's the deepest so far, record it.
Modu
@@ -385,6 +385,49 @@ Users need to implement a single function to capture the
CF table at startup:
// the collected control flow.
}
+Tracing Stack Depth
+===
+
+With ``-fsanitize-coverage=stack-depth`` the compiler will track how much
+stack space has be
@@ -385,6 +385,49 @@ Users need to implement a single function to capture the
CF table at startup:
// the collected control flow.
}
+Tracing Stack Depth
+===
+
+With ``-fsanitize-coverage=stack-depth`` the compiler will track how much
+stack space has be
@@ -385,6 +385,49 @@ Users need to implement a single function to capture the
CF table at startup:
// the collected control flow.
}
+Tracing Stack Depth
+===
+
+With ``-fsanitize-coverage=stack-depth`` the compiler will track how much
+stack space has be
@@ -385,6 +385,49 @@ Users need to implement a single function to capture the
CF table at startup:
// the collected control flow.
}
+Tracing Stack Depth
+===
+
+With ``-fsanitize-coverage=stack-depth`` the compiler will track how much
+stack space has be
@@ -2361,6 +2361,13 @@ def fsanitize_coverage_ignorelist : Joined<["-"],
"fsanitize-coverage-ignorelist
HelpText<"Disable sanitizer coverage instrumentation for modules and
functions "
"that match the provided special case list, even the allowed
ones">,
https://github.com/melver commented:
Generally LGTM - but let's also wait for others to comment.
Documentation of this feature is lacking (and afaik also wasn't added in
https://reviews.llvm.org/D36839). Given this will be used in the kernel, some
kind of official documentation might be good t
https://github.com/melver approved this pull request.
https://github.com/llvm/llvm-project/pull/138323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -2361,6 +2361,13 @@ def fsanitize_coverage_ignorelist : Joined<["-"],
"fsanitize-coverage-ignorelist
HelpText<"Disable sanitizer coverage instrumentation for modules and
functions "
"that match the provided special case list, even the allowed
ones">,
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/138323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -1078,22 +1092,44 @@ void
ModuleSanitizerCoverage::InjectCoverageAtBlock(Function &F, BasicBlock &BB,
Store->setNoSanitizeMetadata();
}
if (Options.StackDepth && IsEntryBB && !IsLeafFunc) {
-// Check stack depth. If it's the deepest so far, record it.
Modu
https://github.com/melver requested changes to this pull request.
This is also missing flag and IR tests.
https://github.com/llvm/llvm-project/pull/138323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/li
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/138323
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -34,6 +34,7 @@ class SanitizerArgs {
std::vector CoverageIgnorelistFiles;
std::vector BinaryMetadataIgnorelistFiles;
int CoverageFeatures = 0;
+ int StackDepthCallbackMin = 0;
melver wrote:
`CoverageStackDepthCallbackMin`
https://github.com/llvm/llv
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/137133
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/137133
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/137133
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From a8319028f08192ca6140beed7f27a83a829c6d84 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
Author: Marco Elver
Date: 2025-04-30T08:49:15+02:00
New Revision: 4bf93c098c8b04a06f228b05732d691d0ce2babc
URL:
https://github.com/llvm/llvm-project/commit/4bf93c098c8b04a06f228b05732d691d0ce2babc
DIFF:
https://github.com/llvm/llvm-project/commit/4bf93c098c8b04a06f228b05732d691d0ce2babc.diff
L
@@ -388,7 +395,7 @@ class SExprBuilder {
til::LiteralPtr *createVariable(const VarDecl *VD);
// Create placeholder for this: we don't know the VarDecl on construction
yet.
- std::pair
+ std::pair
melver wrote:
I think this code is just more complex tha
@@ -81,26 +81,25 @@ static bool isCalleeArrow(const Expr *E) {
return ME ? ME->isArrow() : false;
}
-static StringRef ClassifyDiagnostic(const CapabilityAttr *A) {
- return A->getName();
-}
-
-static StringRef ClassifyDiagnostic(QualType VDT) {
+static CapabilityExpr makeCa
@@ -235,6 +266,20 @@ class FactSet {
return false;
}
+ std::optional replaceLock(FactManager &FM, iterator It,
+std::unique_ptr Entry) {
+if (It == end())
+ return std::nullopt;
+FactID F = FM.newFact(std::move(Entry));
+
@@ -271,26 +271,32 @@ class CFGWalker {
// translateAttrExpr needs it, but that should be moved too.
class CapabilityExpr {
private:
- /// The capability expression and whether it's negated.
- llvm::PointerIntPair CapExpr;
+ /// The capability expression and flags.
+ llvm::
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From d3324c1023533bf784a3c3c3ef095d07c865e6f9 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From d3324c1023533bf784a3c3c3ef095d07c865e6f9 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
melver wrote:
> I think the biggest issue is that removing `const` from `FactEntry` does not
> work. You'll have to undo all those changes and instead create a new
> `FactEntry` for every lock/unlock.
Good catch, reworked this.
PTAL.
https://github.com/llvm/llvm-project/pull/137133
__
@@ -434,6 +434,16 @@ class can be used as a capability. The string argument
specifies the kind of
capability in error messages, e.g. ``"mutex"``. See the ``Container`` example
given above, or the ``Mutex`` class in :ref:`mutexheader`.
+REENTRANT
+-
+
+``REENTRANT``
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From d3324c1023533bf784a3c3c3ef095d07c865e6f9 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From d3324c1023533bf784a3c3c3ef095d07c865e6f9 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
@@ -3990,6 +3990,13 @@ def LocksExcluded : InheritableAttr {
let Documentation = [Undocumented];
}
+def ReentrantCapability : InheritableAttr {
+ let Spellings = [Clang<"reentrant_capability">];
+ let Subjects = SubjectList<[Record, TypedefName]>;
+ let Documentation = [U
@@ -1831,15 +1852,15 @@ void BuildLockset::handleCall(const Expr *Exp, const
NamedDecl *D,
assert(!Self);
const auto *TagT = Exp->getType()->getAs();
if (D->hasAttrs() && TagT && Exp->isPRValue()) {
- std::pair Placeholder =
- Analyzer->SxBuilder.crea
@@ -271,26 +271,32 @@ class CFGWalker {
// translateAttrExpr needs it, but that should be moved too.
class CapabilityExpr {
private:
- /// The capability expression and whether it's negated.
- llvm::PointerIntPair CapExpr;
+ /// The capability expression and flags.
+ llvm::
@@ -163,15 +184,15 @@ using FactID = unsigned short;
/// the analysis of a single routine.
class FactManager {
private:
- std::vector> Facts;
+ std::vector> Facts;
melver wrote:
Fixed.
I guess we have to do clone-mutate-replace of the FactEntries - a little
Author: Marco Elver
Date: 2025-04-25T09:56:54+02:00
New Revision: a9788e3a86cab64ae92dd7d041718b0722f43c3a
URL:
https://github.com/llvm/llvm-project/commit/a9788e3a86cab64ae92dd7d041718b0722f43c3a
DIFF:
https://github.com/llvm/llvm-project/commit/a9788e3a86cab64ae92dd7d041718b0722f43c3a.diff
L
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From c60ccbc31de8e81e6a4af915a83b8271f58f8e7e Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/137133
>From c60ccbc31de8e81e6a4af915a83b8271f58f8e7e Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 23 Apr 2025 11:31:25 +0200
Subject: [PATCH 1/2] Thread Safety Analysis: Convert CapabilityExpr::CapExpr
to hol
melver wrote:
In
https://lore.kernel.org/all/CANpmjNPquO=W1JAh1FNQb8pMQjgeZAKCPQUAd7qUg=5pjJ6x=q...@mail.gmail.com/
I wrote:
> 1. Re-entrant acquires: rcu_read_lock(), preempt_disable(), etc. are
> all re-entrant locks. My proposal is to introduce an attribute that
> can be added to "ACQUIRE(.
https://github.com/melver created
https://github.com/llvm/llvm-project/pull/137133
Introduce the `reentrant_capability` attribute, which may be specified
alongside the `capability(..)` attribute to denote that the defined
capability type is reentrant. Marking a capability as reentrant means
that
https://github.com/melver closed
https://github.com/llvm/llvm-project/pull/123063
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
melver wrote:
Committed!
> Looks good to me, and thanks for the contribution!
Thanks for your review!
Fingers crossed the Linux kernel changes will also land soon.
> > Note, I think for now it might be safer to not enable by default yet, but
> > I've made a note (and hinted at in changelog)
https://github.com/melver closed
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: Marco Elver
Date: 2025-02-26T16:34:33+01:00
New Revision: 3c8c0d4d8d9bbc160d160e683f7a74fd28574dc6
URL:
https://github.com/llvm/llvm-project/commit/3c8c0d4d8d9bbc160d160e683f7a74fd28574dc6
DIFF:
https://github.com/llvm/llvm-project/commit/3c8c0d4d8d9bbc160d160e683f7a74fd28574dc6.diff
L
Author: Marco Elver
Date: 2025-02-26T16:34:33+01:00
New Revision: de10e44b6fe7f3d3cfde3afd8e1222d251172ade
URL:
https://github.com/llvm/llvm-project/commit/de10e44b6fe7f3d3cfde3afd8e1222d251172ade
DIFF:
https://github.com/llvm/llvm-project/commit/de10e44b6fe7f3d3cfde3afd8e1222d251172ade.diff
L
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/123063
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/127396
>From f9fec4c8415b2b9c802b1d7ecdcc9f5cb038f7be Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Sun, 16 Feb 2025 14:53:41 +0100
Subject: [PATCH 1/2] Thread Safety Analysis: Handle address-of followed by
derefere
melver wrote:
> I think this looks very good! I just have some minor remarks.
>
> Thanks to @aoates for trying this out, this is always appreciated!
>
> And sorry for the delay.
Thanks for the review! I addressed the comments, PTAL.
Note, I think for now it might be safer to not enable by def
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/127396
>From f9fec4c8415b2b9c802b1d7ecdcc9f5cb038f7be Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Sun, 16 Feb 2025 14:53:41 +0100
Subject: [PATCH 1/2] Thread Safety Analysis: Handle address-of followed by
derefere
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -4955,13 +4968,18 @@ class Foo {
//showDataCell(*datap2_); // xpected-warning {{reading the value pointed
to by 'datap2_' requires holding mutex 'mu_'}}
int a = data_[0]; // expected-warning {{reading variable 'data_'
requires holding mutex 'mu_'}}
+
+(v
@@ -528,6 +529,9 @@ for a period of time, after which they are migrated into
the standard analysis.
* ``-Wthread-safety-beta``: New features. Off by default.
+ + ``-Wthread-safety-pointer``: Checks when passing or returning pointers to
+guarded variables, or pointers
@@ -528,6 +529,9 @@ for a period of time, after which they are migrated into
the standard analysis.
* ``-Wthread-safety-beta``: New features. Off by default.
+ + ``-Wthread-safety-pointer``: Checks when passing or returning pointers to
+guarded variables, or pointers
@@ -6087,9 +6215,37 @@ class Return {
const Foo &returns_constref_shared_locks_required()
SHARED_LOCKS_REQUIRED(mu) {
return foo;
}
+
+ Foo *returns_ptr_exclusive_locks_required() EXCLUSIVE_LOCKS_REQUIRED(mu) {
+return &foo;
+ }
+
+ Foo *returns_pt_ptr_exclusive
melver wrote:
> I only have a few comments about documenting the caveats (no alias analysis).
>
> The actual code changes look very simple and this looks like a clear
> improvement that would catch many useful cases.
>
> I don't have much experience with this code and would still advise to wai
@@ -143,6 +143,11 @@ Improvements to Clang's diagnostics
- A statement attribute applied to a ``case`` label no longer suppresses
'bypassing variable initialization' diagnostics (#84072).
+- The :doc:`ThreadSafetyAnalysis` now supports ``-Wthread-safety-pointer``
---
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/127396
>From a70f021becb2888d6c2a63b2d1e619393a996058 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Sun, 16 Feb 2025 14:53:41 +0100
Subject: [PATCH 1/2] Thread Safety Analysis: Handle address-of followed by
derefere
melver wrote:
> > I need to commit this by end of day Wednesday - if I should wait a little
> > longer, let me know so I can plan around it. Thanks.
>
> Sorry, but I'm at C standards meetings this week, so I don't think I'll be
> able to review it by then. CC @aaronpuchert who maybe can help?
melver wrote:
Gentle ping.
Thanks!
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
melver wrote:
> I'm very excited about this, as I have wanted it for many years for my C
> codebase, and TSA is not super useful in C without this!
This PR is being superseded by https://github.com/llvm/llvm-project/pull/127396
(implementation changed completely) - we agreed to go with the mor
melver wrote:
FWIW, I'm ready for sending a v2 series to the Linux kernel mailing list:
https://git.kernel.org/pub/scm/linux/kernel/git/melver/linux.git/log/?h=cap-analysis/dev
But I'd like to sort out this PR first before sending the v2 series.
https://github.com/llvm/llvm-project/pull/127396
melver wrote:
(Side-note: I cannot figure out what the canonical way to do "stacked commits"
is for LLVM these days, so I'm just doing this the "old" way i.e. plain and
simple normal git commits which I will commit separately after PR review.)
https://github.com/llvm/llvm-project/pull/127396
_
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver converted_to_draft
https://github.com/llvm/llvm-project/pull/123063
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
melver wrote:
[...]
> Then we only need to make sure that `checkPtAccess` can look through `&`, as
> mentioned above. (Casts should already be unwrapped.) This might not even
> need a new flag, it's just closing a gap in the existing analysis.
Thanks for the suggestions!
I implemented both -
melver wrote:
Superseded by https://github.com/llvm/llvm-project/pull/127396
https://github.com/llvm/llvm-project/pull/127397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver closed
https://github.com/llvm/llvm-project/pull/127397
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/127396
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/127396
>From a70f021becb2888d6c2a63b2d1e619393a996058 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Sun, 16 Feb 2025 14:53:41 +0100
Subject: [PATCH 1/2] Thread Safety Analysis: Handle address-of followed by
derefere
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/127396
>From 13e86fc43071af4c926d3c2d4662423f5c5b4fe8 Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Sun, 16 Feb 2025 12:42:06 +0100
Subject: [PATCH] Thread Safety Analysis: Support warning on passing/returning
point
https://github.com/melver created
https://github.com/llvm/llvm-project/pull/127397
Correctly analyze expressions where the address of a guarded variable is taken
and immediately dereferenced, such as (*(type-specifier *)&x). Previously, such
patterns would result in false negatives.
>From a70
https://github.com/melver created
https://github.com/llvm/llvm-project/pull/127396
Introduce `-Wthread-safety-pointer` (under `-Wthread-safety-beta`) to warn when
passing or returning pointers to guarded variables or guarded data. This is is
analogous to `-Wthread-safety-reference`, which perf
melver wrote:
Addressed comments so far.
> > 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 basi
@@ -515,8 +515,18 @@ Warning flags
+ ``-Wthread-safety-analysis``: The core analysis.
+ ``-Wthread-safety-precise``: Requires that mutex expressions match
precisely.
This warning can be disabled for code which has a lot of aliases.
- + ``-Wthread-safety-reference``
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/123063
>From 6727047d25b8b72f8e23b03a84c0b23f6dad566a Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 15 Jan 2025 13:23:14 +0100
Subject: [PATCH 1/5] Thread Safety Analysis: Support warning on obtaining
address o
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/123063
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/123063
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
melver wrote:
> Doesn't `counted_by` have the same requirements? If not, why does guarded_by?
It does, AFAIK.
> Sure, I can imagine where there might be pushback, but perhaps its worthwhile
> to see how far you can get with either marking structs that don't need
> `-fexperimental-late-parse-a
melver wrote:
> Can any of the members in the structs be reorganized to put the mutex member
> declaration BEFORE the members they guard? Probably not always, but perhaps
> that's possible for most structures?
It's an option I considered, but I can already hear "what is this crap ...
NACK". I
melver wrote:
> Looks like the kernel patches
> [use](https://github.com/google/kernel-sanitizers/commit/81883e1fa377d866c288192b6eb8334bcf10f38f)
> `-fexperimental-late-parse-attributes`? :(
Yeah, no way around it if we want to have guarded_by in structs work properly.
If the problem is cost
melver wrote:
FWIW, the Linux kernel integration (draft, WIP) currently lives here:
https://github.com/google/kernel-sanitizers/tree/cap-analysis
It currently enables -Wthread-safety-addressof if available. Thus far, I have
not found any false positives due to -Wthread-safety-addressof in the 2
melver wrote:
> RFC regarding canonical wrapping/non-wrapping types in Clang:
> https://discourse.llvm.org/t/rfc-clang-canonical-wrapping-and-non-wrapping-types/84356
>
> Ultimately, a type like what the RFC describes would supersede this PR in
> terms of feature completeness and usefulness. I
@@ -433,6 +433,26 @@ Attribute Changes in Clang
- Fix a bug where clang doesn't automatically apply the ``[[gsl::Owner]]`` or
``[[gsl::Pointer]]`` to STL explicit template specialization decls.
(#GH109442)
+- Introduced ``__attribute__((wraps))`` which can be added to type
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/123063
>From 6727047d25b8b72f8e23b03a84c0b23f6dad566a Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 15 Jan 2025 13:23:14 +0100
Subject: [PATCH 1/3] Thread Safety Analysis: Support warning on obtaining
address o
https://github.com/melver edited
https://github.com/llvm/llvm-project/pull/123063
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
https://github.com/melver updated
https://github.com/llvm/llvm-project/pull/123063
>From 6727047d25b8b72f8e23b03a84c0b23f6dad566a Mon Sep 17 00:00:00 2001
From: Marco Elver
Date: Wed, 15 Jan 2025 13:23:14 +0100
Subject: [PATCH 1/3] Thread Safety Analysis: Support warning on obtaining
address o
melver wrote:
> We had a discussion on https://reviews.llvm.org/D52395 that might be relevant
> here. To quote @delesley:
>
> > When you pass an object to a function, either by pointer or by reference,
> > no actual load from memory has yet occurred. Thus, there is a real risk of
> > false po
melver wrote:
Was this dropped? It'd be nice to see this change land.
https://github.com/llvm/llvm-project/pull/99919
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
melver wrote:
For additional background: I'm trying to work out how to bring -Wthread-safety
to the Linux kernel. Since -fexperimental-late-parse-attributes made the
feature practical for complex C structs, I started to look at a strategy to
enable the feature.
The current strategy is to cre
1 - 100 of 137 matches
Mail list logo
