[PATCH] D106614: [Clang] add btf_tag attribute

Yonghong Song via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Aug 3 00:01:57 PDT 2021


yonghong-song added inline comments.


================
Comment at: clang/lib/Sema/SemaDeclAttr.cpp:6841
+  if (auto *Rec = dyn_cast<RecordDecl>(D)) {
+    if (!Rec->isCompleteDefinition()) {
+      S.Diag(AL.getLoc(), diag::warn_btftag_attribute_fwd_decl_ignored) << Str;
----------------
aaron.ballman wrote:
> Does this work for code like:
> ```
> struct __attribute__((btf_tag(""))) S {
>   int x;
> };
> ```
> (I didn't see a test case for the attribute being written in that location.)
Yes, I missed this one as typically I (and kernel developers) write the attribute at the end of definition. I just checked that if we put attribute before the struct name, when the attribute is handled/merged, it is actually an incomplete definition.


================
Comment at: clang/test/Sema/attr-btf_tag.c:31
+
+int __tag2 foo(struct t1 *arg); // expected-warning {{attribute 'btf_tag("tag2")' ignored as not in later redeclaration or definition}}
+int __tag foo(struct t1 *arg);
----------------
aaron.ballman wrote:
> This looks backwards to me -- I think the initial declaration of `foo()` is fine and shouldn't be diagnosed, it's the subsequent declarations of `foo()` with a different `btf_tag` argument that should be diagnosed.
> 
> I think additional test cases for these semantics is:
> ```
> void bar();
> void __tag bar(); // (I think I understood that you want this to diagnose.)
> 
> void __tag bar();
> void bar(); // (But that you don't want this to diagnose.)
> ```
> 
There are a little complication here. Maybe you can give some advice.
We could have code like
   D1: void __tag1 __tag2 bar();
   D2: void bar();
The reason is that we explicitly allow multiple btf_tag's in the same declaration and this is exactly our use case.

Current merge*Attribute() framework will take one attribute at a time.
For example, first we will do
    mergeBTFTagAttribute(D2, __tag1):
      Here, we add __tag1 to D2, so we have
       D2: void __tag1 bar();
we then do
    mergeBTFTagAttribute(D2, __tag2):
      but D2 already has a __tag1 which is incompatible with __tag2, and
      we will issue an error here. But it is incorrect to issue an error
      since the correct semantics is to inherit both __tag1 and __tag2 for D2.

Let me take a look at the code how to best handle such cases. Please also let me know if you have any suggestions. thanks!

A little bit more. The following are possible cases to check:
   (1)  void bar();
         void __tag1 __tag2 bar();  // fail
   (2).  void __tag1 bar();
         void __tag1 __tag2 bar(); // fail
   (3)   void __tag1 __tag2 bar();
         void __tag1 __tag2 bar();  // succeed
   (4). void __tag1 __tag2 __tag3 bar();
         void __tag1 __tag2 bar();   // fail
   (5). void __tag3 bar();
         void __tag1 __tag2 bar(); // fail
   (6). void __tag1 __tag2 bar();
         void bar()  // succeed

Basically, for two same declaration except attributes, D1, D2,
   no error/warning only if D2 has no btf_tag attributes, or
   D1 and D2 have identical btf_tag attributes.
Do this sound reasonable?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D106614/new/

https://reviews.llvm.org/D106614



More information about the cfe-commits mailing list