<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 10, 2021 at 12:10 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.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">On Thu, Jun 10, 2021 at 2:45 PM Y Song <<a href="mailto:ys114321@gmail.com" target="_blank">ys114321@gmail.com</a>> wrote:<br>
><br>
> On Thu, Jun 10, 2021 at 11:29 AM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
> ><br>
> > On Thu, Jun 10, 2021 at 11:09 AM Y Song <<a href="mailto:ys114321@gmail.com" target="_blank">ys114321@gmail.com</a>> wrote:<br>
> >><br>
> >> 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>
> ><br>
> ><br>
> > Good to know/understand.<br>
> ><br>
> >><br>
> >><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>
> ><br>
> ><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" rel="noreferrer" target="_blank">https://clang.llvm.org/docs/AttributeReference.html</a><br>
><br>
> Looks like this attribute is not well documented.<br>
<br>
Correct -- it's an ancient attribute that predates us documenting<br>
attributes at all.<br>
<br>
> I forgot how I found it. But below is a public blog on how it could be used:<br>
> <a href="https://blog.quarkslab.com/implementing-a-custom-directive-handler-in-clang.html" rel="noreferrer" target="_blank">https://blog.quarkslab.com/implementing-a-custom-directive-handler-in-clang.html</a><br>
> I then went to<br>
> clang/include/clang/Basic/Attr.td<br>
> and found<br>
><br>
> def Annotate : InheritableParamAttr {<br>
> let Spellings = [Clang<"annotate">];<br>
> let Args = [StringArgument<"Annotation">, VariadicExprArgument<"Args">];<br>
> // Ensure that the annotate attribute can be used with<br>
> // '#pragma clang attribute' even though it has no subject list.<br>
> let AdditionalMembers = [{<br>
> static AnnotateAttr *Create(ASTContext &Ctx, llvm::StringRef Annotation, \<br>
> const AttributeCommonInfo &CommonInfo) {<br>
> return AnnotateAttr::Create(Ctx, Annotation, nullptr, 0, CommonInfo);<br>
> }<br>
> static AnnotateAttr *CreateImplicit(ASTContext &Ctx, llvm::StringRef<br>
> Annotation, \<br>
> const AttributeCommonInfo &CommonInfo = {SourceRange{}}) {<br>
> return AnnotateAttr::CreateImplicit(Ctx, Annotation, nullptr, 0,<br>
> CommonInfo);<br>
> }<br>
> }];<br>
> let PragmaAttributeSupport = 1;<br>
> let Documentation = [Undocumented];<br>
> }<br>
><br>
> and tried to use it for places BPF cares about and it all covers.<br>
<br>
I don't think it's a good idea to use annotate for BPF needs. The<br>
basic idea behind annotate is that it's a way to pass arbitrary string<br>
(and starting very recently, other kinds of constant expressions) from<br>
the frontend to the backend. So it's a general-purpose tool that's<br>
used for one-off situations. As an example, attribute plugins will use<br>
it because they cannot currently create their own semantic attribute<br>
easily, and I think the static analyzer may make use of the feature as<br>
well. Because the BPF needs are so specific, I think it'd be better to<br>
use an attribute dedicated to those needs rather than using a<br>
general-purpose attribute like annotate -- this will reduce the<br>
likelihood of conflicts with the other creative uses people put<br>
annotate to.<br></blockquote><div><br></div><div>Any suggestions/preferences for the spelling, Aaron?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> BTW, the above attr definition does say Undocumented.<br>
<br>
Yeah, the build requires there to be some documentation for every<br>
attribute, and Undocumented is what we use for attributes that we<br>
elect not to document because they're implementation details (rarely)<br>
or have failed to document yet (much more common).<br>
<br>
HTH!<br>
<br>
~Aaron<br>
<br>
><br>
> ><br>
> >><br>
> >><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>