[Clang] Implement function attribute nouwtable

[ychen]

Summary

To have finer control of IR uwtable attribute generation. For target code generation,
IR nounwind and uwtable may have some interaction. However, for frontend, there are
no semantic interactions so the this new nouwtable is marked "SimpleHandler = 1".

[ychen]

• update test

[aaron.ballman]

Do we have any evidence that users need this level of control or will understand how to properly use the attribute? The command line option makes sense to me because it's an all-or-nothing flag, but I'm not certain I understand the need for per-function control. Also, if a user gets this wrong (applies the attribute where they shouldn't), what is the failure mode (does it introduce any exploitable behavior)?

[ychen]

Thanks for taking a look!

In D132592#3749261, @aaron.ballman wrote:

Do we have any evidence that users need this level of control or will understand how to properly use the attribute? The command line option makes sense to me because it's an all-or-nothing flag, but I'm not certain I understand the need for per-function control.

https://github.com/llvm/llvm-project/blob/064a08cd955019da9130f1109bfa534e79b8ec7c/llvm/include/llvm/IR/Function.h#L639-L641, per-function unwind table entry depends on both nounwind and uwtable. We have nothrow attribute for nounwind but not nouwtable for uwtable. With this, a user could use function attributes to control unwind table entry generation which could only be achieved by inline assembly or writing assembly files directly. I'd consider this a companion of nothrow. So making them both per-function attribute seems natural?

Also, if a user gets this wrong (applies the attribute where they shouldn't), what is the failure mode (does it introduce any exploitable behavior)?

The flag may only suppress unwind table emission instead of causing more, the lack of unwind table may only stop control flow rather than giving it more freedom. So I think this is safe from a security perspective. Using it wrong may cause unnecessary crashes just like any other memory bugs, but not a malicious binary.

[aaron.ballman]

In D132592#3749567, @ychen wrote:

Thanks for taking a look!

In D132592#3749261, @aaron.ballman wrote:

Do we have any evidence that users need this level of control or will understand how to properly use the attribute? The command line option makes sense to me because it's an all-or-nothing flag, but I'm not certain I understand the need for per-function control.

https://github.com/llvm/llvm-project/blob/064a08cd955019da9130f1109bfa534e79b8ec7c/llvm/include/llvm/IR/Function.h#L639-L641, per-function unwind table entry depends on both nounwind and uwtable. We have nothrow attribute for nounwind but not nouwtable for uwtable. With this, a user could use function attributes to control unwind table entry generation which could only be achieved by inline assembly or writing assembly files directly. I'd consider this a companion of nothrow. So making them both per-function attribute seems natural?

Also, if a user gets this wrong (applies the attribute where they shouldn't), what is the failure mode (does it introduce any exploitable behavior)?

The flag may only suppress unwind table emission instead of causing more, the lack of unwind table may only stop control flow rather than giving it more freedom. So I think this is safe from a security perspective. Using it wrong may cause unnecessary crashes just like any other memory bugs, but not a malicious binary.

Thank you for the explanations, that helped. :-)

You're missing all of the semantic tests (that the attr takes no arguments, only applies to function-like things, etc). Also, the subject you picked is FunctionLike so you should have some test coverage showing how this works when calling through a function pointer with the attribute (or you should pick a more appropriate subject if that one is wrong).

clang/include/clang/Basic/AttrDocs.td

4545–4546

[ychen]

• change from FunctionLike to Function
• add a Sema test
• update doc

[ychen]

In D132592#3751561, @aaron.ballman wrote:

In D132592#3749567, @ychen wrote:

Thanks for taking a look!

In D132592#3749261, @aaron.ballman wrote:

Do we have any evidence that users need this level of control or will understand how to properly use the attribute? The command line option makes sense to me because it's an all-or-nothing flag, but I'm not certain I understand the need for per-function control.

https://github.com/llvm/llvm-project/blob/064a08cd955019da9130f1109bfa534e79b8ec7c/llvm/include/llvm/IR/Function.h#L639-L641, per-function unwind table entry depends on both nounwind and uwtable. We have nothrow attribute for nounwind but not nouwtable for uwtable. With this, a user could use function attributes to control unwind table entry generation which could only be achieved by inline assembly or writing assembly files directly. I'd consider this a companion of nothrow. So making them both per-function attribute seems natural?

Also, if a user gets this wrong (applies the attribute where they shouldn't), what is the failure mode (does it introduce any exploitable behavior)?

The flag may only suppress unwind table emission instead of causing more, the lack of unwind table may only stop control flow rather than giving it more freedom. So I think this is safe from a security perspective. Using it wrong may cause unnecessary crashes just like any other memory bugs, but not a malicious binary.

Thank you for the explanations, that helped. :-)

You're missing all of the semantic tests (that the attr takes no arguments, only applies to function-like things, etc). Also, the subject you picked is FunctionLike so you should have some test coverage showing how this works when calling through a function pointer with the attribute (or you should pick a more appropriate subject if that one is wrong).

Yes, Function is more proper than FunctionLike.

[aaron.ballman]

LGTM, though please add a release note for the new attribute.

[ychen]

• add a release note.

clang/docs/ReleaseNotes.rst

 
 New Pragmas in Clang
 --------------------
 - ...
 
 Attribute Changes in Clang
 --------------------------
 
+- Introduced a new function attribute ``__attribute__((nouwtable))`` to suppress
+  LLVM IR ``uwtable`` function attribute.
+
 Windows Support
 ---------------
 
 AIX Support
 -----------
 
 C Language Changes in Clang
 ---------------------------

clang/include/clang/Basic/Attr.td

 }
 
 def NoThrow : InheritableAttr {
   let Spellings = [GCC<"nothrow">, Declspec<"nothrow">];
   let Subjects = SubjectList<[FunctionLike]>;
   let Documentation = [NoThrowDocs];
 }
 
+def NoUwtable : InheritableAttr {
+  let Spellings = [Clang<"nouwtable">];
+  let Subjects = SubjectList<[FunctionLike]>;
+  let Documentation = [NoUwtableDocs];
+  let SimpleHandler = 1;
+}
+
 def NvWeak : IgnoredAttr {
   // No Declspec spelling of this attribute; the CUDA headers use
   // __attribute__((nv_weak)) unconditionally. Does not receive an [[]]
   // spelling because it is a CUDA attribute.
   let Spellings = [GNU<"nv_weak">];
   let LangOpts = [CUDA];
 }
 

clang/include/clang/Basic/AttrDocs.td

 ``__declspec(nothrow)`` attribute as an equivalent of ``noexcept`` on function
 declarations. This attribute informs the compiler that the annotated function
 does not throw an exception. This prevents exception-unwinding. This attribute
 is particularly useful on functions in the C Standard Library that are
 guaranteed to not throw an exception.
     }];
 }
 
+def NoUwtableDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+Clang supports the ``nouwtable`` attribute which skips emitting
+the unwind table entry for the specified function. This attribute is useful for
+selectively emitting the unwind table entry on some functions when building with
+``-funwind-tables`` compiler option.
+    }];
+}
+
 def InternalLinkageDocs : Documentation {
   let Category = DocCatFunction;
   let Content = [{
 The ``internal_linkage`` attribute changes the linkage type of the declaration
 to internal. This is similar to C-style ``static``, but can be used on classes
 and class methods. When applied to a class definition, this attribute affects
 all methods and static data members of that class. This can be used to contain
 the ABI of a C++ library by excluding unwanted class methods from the export

clang/lib/CodeGen/CodeGenModule.cpp

CodeGenModule::GetOrCreateRTTIProxyGlobalVariable(llvm::Constant *Addr) {
   RTTIProxyMap[Addr] = FTRTTIProxy;
   return FTRTTIProxy;
 }
 
 void CodeGenModule::SetLLVMFunctionAttributesForDefinition(const Decl *D,
                                                            llvm::Function *F) {
   llvm::AttrBuilder B(F->getContext());
 
-  if (CodeGenOpts.UnwindTables)
+  if ((!D || !D->hasAttr<NoUwtableAttr>()) && CodeGenOpts.UnwindTables)
     B.addUWTableAttr(llvm::UWTableKind(CodeGenOpts.UnwindTables));
 
   if (CodeGenOpts.StackClashProtector)
     B.addAttribute("probe-stack", "inline-asm");
 
   if (!hasUnwindExceptions(LangOpts))
     B.addAttribute(llvm::Attribute::NoUnwind);
 

clang/test/CodeGen/attr-nouwtable.c

+// RUN: %clang_cc1 -funwind-tables=2 -S -emit-llvm %s -o - | FileCheck %s
+
+__attribute__((nouwtable))
+int test1(void) { return 0; }
+
+// CHECK: @test1{{.*}}[[ATTR1:#[0-9]+]]
+// CHECK: attributes [[ATTR1]] = {
+// CHECK-NOT: uwtable
+// CHECK: }

clang/test/Misc/pragma-attribute-supported-attributes-list.test

 // CHECK-NEXT: NoRandomizeLayout (SubjectMatchRule_record)
 // CHECK-NEXT: NoSanitize (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_variable_is_global)
 // CHECK-NEXT: NoSanitizeSpecific (SubjectMatchRule_function, SubjectMatchRule_variable_is_global)
 // CHECK-NEXT: NoSpeculativeLoadHardening (SubjectMatchRule_function, SubjectMatchRule_objc_method)
 // CHECK-NEXT: NoSplitStack (SubjectMatchRule_function)
 // CHECK-NEXT: NoStackProtector (SubjectMatchRule_function)
 // CHECK-NEXT: NoThreadSafetyAnalysis (SubjectMatchRule_function)
 // CHECK-NEXT: NoThrow (SubjectMatchRule_hasType_functionType)
+// CHECK-NEXT: NoUwtable (SubjectMatchRule_hasType_functionType)
 // CHECK-NEXT: NotTailCalled (SubjectMatchRule_function)
 // CHECK-NEXT: OSConsumed (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: OSReturnsNotRetained (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: OSReturnsRetained (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_objc_property, SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: OSReturnsRetainedOnNonZero (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: OSReturnsRetainedOnZero (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: ObjCBoxable (SubjectMatchRule_record)
 // CHECK-NEXT: ObjCBridge (SubjectMatchRule_record, SubjectMatchRule_type_alias)