<div dir="ltr">(Crossposting to cfe-dev because this includes a proposal for a new C/C++ level attribute)<br><br>These attributes are all effectively hand-written (with or without macros) in the input source? None of them are derived by the compiler frontend based on other characteristics?<br><br>And I'm guessing maybe we'd want the name to be a bit narrower, like bpf_annotate, perhaps - taking such a generic term as "annotate" in the global attribute namespace seems fairly bold for what's currently a fairly narrow use case. <a class="gmail_plusreply" id="plusReplyChip-0" href="mailto:aaron@aaronballman.com" tabindex="-1">+Aaron Ballman</a> thoughts on this?<div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 9, 2021 at 7:42 PM Y Song <<a href="mailto:ys114321@gmail.com">ys114321@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
This feature is for the BPF community. The detailed use case is<br>
described in <a href="https://reviews.llvm.org/D103549" rel="noreferrer" target="_blank">https://reviews.llvm.org/D103549</a>. And I have crafted a<br>
WIP patch <a href="https://reviews.llvm.org/D103667" rel="noreferrer" target="_blank">https://reviews.llvm.org/D103667</a> which implements necessary<br>
frontend and codegen (plus others) to show the scope of the work.<br>
<br>
To elaborate the use case a little bit more. Basically, we want to put<br>
some annotations into variables (include parameters), functions,<br>
structure/union types and structure/union members. The string<br>
arguments in annotations will not<br>
be interpreted  inside the compiler. The compiler should just emit<br>
these annotations into dwarf. Currently in the linux build system,<br>
pahole will convert dwarf to BTF which will encode these annotation<br>
strings into BTF. The following is a C example how annotations look<br>
like at source level:<br>
<br>
$ cat t1.c<br>
/* a pointer pointing to user memory */<br>
#define __user __attribute__((annotate("user")))<br>
/* a pointer protected by rcu */<br>
#define __rcu __attribute__((annotate("rcu")))<br>
/* the struct has some special property */<br>
#define __special_struct __attribute__((annotate("special_struct")))<br>
/* sock_lock is held for the function */<br>
#define __sock_lock_held __attribute((annotate("sock_lock_held")))<br>
/* the hash table element type is socket */<br>
#define __special_info __attribute__((annotate("elem_type:socket")))<br>
<br>
struct hlist_node;<br>
struct hlist_head {<br>
  struct hlist_node *prev;<br>
  struct hlist_node *next;<br>
} __special_struct;<br>
struct hlist {<br>
   struct hlist_head head __special_info;<br>
};<br>
<br>
extern void bar(struct hlist *);<br>
int foo(struct hlist *h,  int *a __user, int *b __rcu) __sock_lock_held {<br>
  bar(h);<br>
  return *a + *b;<br>
}<br>
<br>
In <a href="https://reviews.llvm.org/D103667" rel="noreferrer" target="_blank">https://reviews.llvm.org/D103667</a>, I implemented a LLVM extended attribute<br>
DWARF_AT_LLVM_annotations. But this might not be the right thing to do<br>
as it is not clear whether there are use cases beyond BPF.<br>
David suggested that we discuss this in llvm-dev to get consensus on<br>
how this feature may be supported in LLVM. Hence this email.<br>
<br>
Please share your comments, suggestions on how to support this feature<br>
in LLVM. Thanks!<br>
<br>
Yonghong<br>
</blockquote></div>