<div dir="ltr"><div dir="ltr">On Thu, Jun 10, 2021 at 11:09 AM Y Song <<a href="mailto:ys114321@gmail.com">ys114321@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Jun 10, 2021 at 10:05 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
><br>
> (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>
Yes, they are hand-written in the input source and fit into the clang<br>
compiler. They are not derived inside the clang/llvm.<br></blockquote><div><br>Good to know/understand.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<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. +Aaron Ballman thoughts on this?<br>
<br>
I am okay with something like bpf_annotate as the existing annotate<br>
attribute will generate global variables or codes for annotations<br>
which is unnecessary for bpf use case,<br>
although the overhead should be quite small.<br></blockquote><div><br>Ah, there's an existing annotate attribute you're proposing leveraging/reusing that? Got a pointer to the documentation for that? I don't see it documented here: <a href="https://clang.llvm.org/docs/AttributeReference.html">https://clang.llvm.org/docs/AttributeReference.html</a><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
><br>
> On Wed, Jun 9, 2021 at 7:42 PM Y Song <<a href="mailto:ys114321@gmail.com" target="_blank">ys114321@gmail.com</a>> wrote:<br>
>><br>
>> 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></div>