<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:31 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 3:16 PM David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
><br>
> On Thu, Jun 10, 2021 at 12:10 PM Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>> wrote:<br>
>><br>
>> 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>
><br>
><br>
> Any suggestions/preferences for the spelling, Aaron?<br>
<br>
I don't know this domain particularly well, so takes these suggestions<br>
with a giant grain of salt:<br>
<br>
If the concept is specific to DWARF and you don't think it'll need to<br>
extend into other debug formats, you could go with `dwarf_annotate`.<br>
If it's not really a DWARF thing but is more about B[P|T]F, then<br>
`btf_annotate` or `bpf_annotate` could work, but those may be a bit<br>
mysterious to folks outside of the domain. If it's a generic debug<br>
info concept, probably `debug_info_annotate` or something.<br></blockquote><div><br></div><div>Arguably it can/could be a generic debug info or dwarf thing, but for now we don't have any use for it other than to squirrel info along to BTF/BPF so I'm on the fence about which prefix to use exactly</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>
My primary concern with reusing `annotate` itself is because user<br>
programs are likely already using that attribute for basically<br>
arbitrary purposes, so I worry reusing it for this purpose may<br>
accidentally expose annotations in debug info that the user never<br>
really expected to be there (which may confuse whatever is reading the<br>
annotations from the debug info).<br></blockquote><div><br>Yeah, +1 there.<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>
~Aaron<br>
<br>
><br>
>><br>
>><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>