Skip to content
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

[UBSAN] Preserve ubsan code with ubsan-unique-traps #83470

Closed
wants to merge 1 commit into from

Conversation

vitalybuka
Copy link
Collaborator

Removing TrapBB->getParent()->size() added with #65972. Counter as-is
is not very unique after inlining https://godbolt.org/z/4KfEKq7zb (see
m()).

Removing `TrapBB->getParent()->size()` added with llvm#65972. Counter as-is
is not very unique after inlining https://godbolt.org/z/4KfEKq7zb (see
m()).
@llvmbot llvmbot added clang Clang issues not falling into any other category clang:codegen labels Feb 29, 2024
@llvmbot
Copy link
Collaborator

llvmbot commented Feb 29, 2024

@llvm/pr-subscribers-clang

@llvm/pr-subscribers-clang-codegen

Author: Vitaly Buka (vitalybuka)

Changes

Removing TrapBB->getParent()->size() added with #65972. Counter as-is
is not very unique after inlining https://godbolt.org/z/4KfEKq7zb (see
m()).


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

2 Files Affected:

  • (modified) clang/lib/CodeGen/CGExpr.cpp (+3-5)
  • (modified) clang/test/CodeGen/bounds-checking.c (+2-2)
diff --git a/clang/lib/CodeGen/CGExpr.cpp b/clang/lib/CodeGen/CGExpr.cpp
index 59a7fe8925001c..ee5f3a2786a627 100644
--- a/clang/lib/CodeGen/CGExpr.cpp
+++ b/clang/lib/CodeGen/CGExpr.cpp
@@ -3826,11 +3826,9 @@ void CodeGenFunction::EmitTrapCheck(llvm::Value *Checked,
     Builder.CreateCondBr(Checked, Cont, TrapBB);
     EmitBlock(TrapBB);
 
-    llvm::CallInst *TrapCall = Builder.CreateCall(
-        CGM.getIntrinsic(llvm::Intrinsic::ubsantrap),
-        llvm::ConstantInt::get(CGM.Int8Ty, ClSanitizeDebugDeoptimization
-                                               ? TrapBB->getParent()->size()
-                                               : CheckHandlerID));
+    llvm::CallInst *TrapCall =
+        Builder.CreateCall(CGM.getIntrinsic(llvm::Intrinsic::ubsantrap),
+                           llvm::ConstantInt::get(CGM.Int8Ty, CheckHandlerID));
 
     if (!CGM.getCodeGenOpts().TrapFuncName.empty()) {
       auto A = llvm::Attribute::get(getLLVMContext(), "trap-func-name",
diff --git a/clang/test/CodeGen/bounds-checking.c b/clang/test/CodeGen/bounds-checking.c
index 8100e30d0650ad..f6c4880e70a150 100644
--- a/clang/test/CodeGen/bounds-checking.c
+++ b/clang/test/CodeGen/bounds-checking.c
@@ -74,11 +74,11 @@ char B2[10];
 // CHECK-LABEL: @f8
 void f8(int i, int k) {
   // NOOPTLOCAL: call void @llvm.ubsantrap(i8 3)
-  // NOOPTARRAY: call void @llvm.ubsantrap(i8 2)
+  // NOOPTARRAY: call void @llvm.ubsantrap(i8 18)
   B[i] = '\0';
 
   // NOOPTLOCAL: call void @llvm.ubsantrap(i8 5)
-  // NOOPTARRAY: call void @llvm.ubsantrap(i8 4)
+  // NOOPTARRAY: call void @llvm.ubsantrap(i8 18)
   B2[k] = '\0';
 }
 

@oskarwirga
Copy link
Contributor

It happens later, in LLVM backend, it needs to be fixed.

From #65972 (comment)

Is this something you have planned to fix? If not would replacing the .size() counter with perhaps a seeded random uint8 be acceptable?

My use case prevents me from shipping the minimal runtime alongside the instrumentation so my goal was to create an improvement (definitely imperfect!) to the debugability of a production deployment of BoundsSan. This PR as is would revert that behavior entirely.

@vitalybuka
Copy link
Collaborator Author

It happens later, in LLVM backend, it needs to be fixed.

From #65972 (comment)

Is this something you have planned to fix? If not would replacing the .size() counter with perhaps a seeded random uint8 be acceptable?

My use case prevents me from shipping the minimal runtime alongside the instrumentation so my goal was to create an improvement (definitely imperfect!) to the debugability of a production deployment of BoundsSan. This PR as is would revert that behavior entirely.

I don't plan to do anything about it.
My point that it does not work even on trivial example as in description.
Unless you/someone else is willing to work on real fix, this behavior is not worse of preserving.

Copy link
Contributor

@oskarwirga oskarwirga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you are going to remove this feature, I would rather you simply revert the old commit. There is no point leaving the flag in at this point.

I had explored earlier dealing with the optimization at a later time in the compilation pipeline, but got nowhere and this solution was ideal for my use case, binary size constraints limited any inlining so I never ran into the issue. I appreciate you cleaning this up! :)

@vitalybuka
Copy link
Collaborator Author

If you are going to remove this feature, I would rather you simply revert the old commit. There is no point leaving the flag in at this point.

I had explored earlier dealing with the optimization at a later time in the compilation pipeline, but got nowhere and this solution was ideal for my use case, binary size constraints limited any inlining so I never ran into the issue. I appreciate you cleaning this up! :)

Actually I am here because I want to use the flag to avoid merging basic blocks.
We are going to opt-out ubsan checks based on PGO, per basic block hotness #83471

However I am considering introducing a special intrinsic for that, the this patch will not be needed.

@vitalybuka
Copy link
Collaborator Author

vitalybuka commented Apr 5, 2024

I changed my design, so I don't need this patch.
Given https://godbolt.org/z/4KfEKq7zb, I can revert your patch, or just leave it as is. I have no preference.

@oskarwirga
Copy link
Contributor

I changed my design, so I don't need this patch. Given https://godbolt.org/z/4KfEKq7zb, I can revert your patch, or just leave it as is. I have no preference.

I would prefer leaving it as is, I will make a note to revisit this pending further testing on my end to see how useful it really is. Thank you :)

@vitalybuka
Copy link
Collaborator Author

abandoning

@vitalybuka vitalybuka closed this Apr 5, 2024
@vitalybuka vitalybuka deleted the nocount branch April 5, 2024 19:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang:codegen clang Clang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants