Skip to content

[HWASan] Handle default attribute on personality function thunks. #141917

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

DanielKristofKiss
Copy link
Member

Function::createWithDefaultAttr deals with default attributes so no need to manually deal with them here.

Function::createWithDefaultAttr deals with default attributes so no need to manually
deal with them here.
@llvmbot
Copy link
Member

llvmbot commented May 29, 2025

@llvm/pr-subscribers-llvm-transforms

@llvm/pr-subscribers-compiler-rt-sanitizer

Author: Daniel Kiss (DanielKristofKiss)

Changes

Function::createWithDefaultAttr deals with default attributes so no need to manually deal with them here.


Full diff: https://github.com/llvm/llvm-project/pull/141917.diff

1 Files Affected:

  • (modified) llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp (+5-10)
diff --git a/llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp b/llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
index e81a725c62ead..e38ee68ce0451 100644
--- a/llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
+++ b/llvm/lib/Transforms/Instrumentation/HWAddressSanitizer.cpp
@@ -1842,16 +1842,11 @@ void HWAddressSanitizer::instrumentPersonalityFunctions() {
         Int32Ty, {Int32Ty, Int32Ty, Int64Ty, PtrTy, PtrTy}, false);
     bool IsLocal = P.first && (!isa<GlobalValue>(P.first) ||
                                cast<GlobalValue>(P.first)->hasLocalLinkage());
-    auto *ThunkFn = Function::Create(ThunkFnTy,
-                                     IsLocal ? GlobalValue::InternalLinkage
-                                             : GlobalValue::LinkOnceODRLinkage,
-                                     ThunkName, &M);
-    // TODO: think about other attributes as well.
-    if (any_of(P.second, [](const Function *F) {
-          return F->hasFnAttribute("branch-target-enforcement");
-        })) {
-      ThunkFn->addFnAttr("branch-target-enforcement");
-    }
+    auto *ThunkFn = Function::createWithDefaultAttr(
+        ThunkFnTy,
+        IsLocal ? GlobalValue::InternalLinkage
+                : GlobalValue::LinkOnceODRLinkage,
+        M.getDataLayout().getProgramAddressSpace(), ThunkName, &M);
     if (!IsLocal) {
       ThunkFn->setVisibility(GlobalValue::HiddenVisibility);
       ThunkFn->setComdat(M.getOrInsertComdat(ThunkName));

@fmayer
Copy link
Contributor

fmayer commented May 29, 2025

What is the aim of this change? IMO the way it was before more explicitly models what we want: now that BTI is determined on a per-function, not per-module basis, this is the information we should use.

@fmayer
Copy link
Contributor

fmayer commented May 30, 2025

See also: #139216

@DanielKristofKiss
Copy link
Member Author

I looked for an other bug related to similar issue when the function created and the compiler flags are disregarded when I saw this change.
A function might not have BTI flag due to function level attribute and the thunk will inherit it but there is no guarantee for the thunk will be called only directly.

@fmayer
Copy link
Contributor

fmayer commented Jun 2, 2025

A function might not have BTI flag due to function level attribute and the thunk will inherit it but there is no guarantee for the thunk will be called only directly.

I don't understand. the current logic is exactly what we want: if the thunk is called from any BTI function, it needs to use BTI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants