David Blaikie via llvm-dev
2021-Jun-10 18:29 UTC
[llvm-dev] put "str" in __attribute__((annotate("str"))) to dwarf
On Thu, Jun 10, 2021 at 11:09 AM Y Song <ys114321 at gmail.com> wrote:> On Thu, Jun 10, 2021 at 10:05 AM David Blaikie <dblaikie at gmail.com> wrote: > > > > (Crossposting to cfe-dev because this includes a proposal for a new > C/C++ level attribute) > > > > 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? > > Yes, they are hand-written in the input source and fit into the clang > compiler. They are not derived inside the clang/llvm. >Good to know/understand.> > > > > 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? > > I am okay with something like bpf_annotate as the existing annotate > attribute will generate global variables or codes for annotations > which is unnecessary for bpf use case, > although the overhead should be quite small. >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: https://clang.llvm.org/docs/AttributeReference.html> > > > > > > On Wed, Jun 9, 2021 at 7:42 PM Y Song <ys114321 at gmail.com> wrote: > >> > >> Hi, > >> > >> This feature is for the BPF community. The detailed use case is > >> described in https://reviews.llvm.org/D103549. And I have crafted a > >> WIP patch https://reviews.llvm.org/D103667 which implements necessary > >> frontend and codegen (plus others) to show the scope of the work. > >> > >> To elaborate the use case a little bit more. Basically, we want to put > >> some annotations into variables (include parameters), functions, > >> structure/union types and structure/union members. The string > >> arguments in annotations will not > >> be interpreted inside the compiler. The compiler should just emit > >> these annotations into dwarf. Currently in the linux build system, > >> pahole will convert dwarf to BTF which will encode these annotation > >> strings into BTF. The following is a C example how annotations look > >> like at source level: > >> > >> $ cat t1.c > >> /* a pointer pointing to user memory */ > >> #define __user __attribute__((annotate("user"))) > >> /* a pointer protected by rcu */ > >> #define __rcu __attribute__((annotate("rcu"))) > >> /* the struct has some special property */ > >> #define __special_struct __attribute__((annotate("special_struct"))) > >> /* sock_lock is held for the function */ > >> #define __sock_lock_held __attribute((annotate("sock_lock_held"))) > >> /* the hash table element type is socket */ > >> #define __special_info __attribute__((annotate("elem_type:socket"))) > >> > >> struct hlist_node; > >> struct hlist_head { > >> struct hlist_node *prev; > >> struct hlist_node *next; > >> } __special_struct; > >> struct hlist { > >> struct hlist_head head __special_info; > >> }; > >> > >> extern void bar(struct hlist *); > >> int foo(struct hlist *h, int *a __user, int *b __rcu) __sock_lock_held > { > >> bar(h); > >> return *a + *b; > >> } > >> > >> In https://reviews.llvm.org/D103667, I implemented a LLVM extended > attribute > >> DWARF_AT_LLVM_annotations. But this might not be the right thing to do > >> as it is not clear whether there are use cases beyond BPF. > >> David suggested that we discuss this in llvm-dev to get consensus on > >> how this feature may be supported in LLVM. Hence this email. > >> > >> Please share your comments, suggestions on how to support this feature > >> in LLVM. Thanks! > >> > >> Yonghong >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210610/d4124bca/attachment.html>
Y Song via llvm-dev
2021-Jun-10 18:44 UTC
[llvm-dev] put "str" in __attribute__((annotate("str"))) to dwarf
On Thu, Jun 10, 2021 at 11:29 AM David Blaikie <dblaikie at gmail.com> wrote:> > On Thu, Jun 10, 2021 at 11:09 AM Y Song <ys114321 at gmail.com> wrote: >> >> On Thu, Jun 10, 2021 at 10:05 AM David Blaikie <dblaikie at gmail.com> wrote: >> > >> > (Crossposting to cfe-dev because this includes a proposal for a new C/C++ level attribute) >> > >> > 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? >> >> Yes, they are hand-written in the input source and fit into the clang >> compiler. They are not derived inside the clang/llvm. > > > Good to know/understand. > >> >> >> > >> > 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? >> >> I am okay with something like bpf_annotate as the existing annotate >> attribute will generate global variables or codes for annotations >> which is unnecessary for bpf use case, >> although the overhead should be quite small. > > > 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: https://clang.llvm.org/docs/AttributeReference.htmlLooks like this attribute is not well documented. I forgot how I found it. But below is a public blog on how it could be used: https://blog.quarkslab.com/implementing-a-custom-directive-handler-in-clang.html I then went to clang/include/clang/Basic/Attr.td and found def Annotate : InheritableParamAttr { let Spellings = [Clang<"annotate">]; let Args = [StringArgument<"Annotation">, VariadicExprArgument<"Args">]; // Ensure that the annotate attribute can be used with // '#pragma clang attribute' even though it has no subject list. let AdditionalMembers = [{ static AnnotateAttr *Create(ASTContext &Ctx, llvm::StringRef Annotation, \ const AttributeCommonInfo &CommonInfo) { return AnnotateAttr::Create(Ctx, Annotation, nullptr, 0, CommonInfo); } static AnnotateAttr *CreateImplicit(ASTContext &Ctx, llvm::StringRef Annotation, \ const AttributeCommonInfo &CommonInfo = {SourceRange{}}) { return AnnotateAttr::CreateImplicit(Ctx, Annotation, nullptr, 0, CommonInfo); } }]; let PragmaAttributeSupport = 1; let Documentation = [Undocumented]; } and tried to use it for places BPF cares about and it all covers. BTW, the above attr definition does say Undocumented.> >> >> >> > >> > >> > On Wed, Jun 9, 2021 at 7:42 PM Y Song <ys114321 at gmail.com> wrote: >> >> >> >> Hi, >> >> >> >> This feature is for the BPF community. The detailed use case is >> >> described in https://reviews.llvm.org/D103549. And I have crafted a >> >> WIP patch https://reviews.llvm.org/D103667 which implements necessary >> >> frontend and codegen (plus others) to show the scope of the work. >> >> >> >> To elaborate the use case a little bit more. Basically, we want to put >> >> some annotations into variables (include parameters), functions, >> >> structure/union types and structure/union members. The string >> >> arguments in annotations will not >> >> be interpreted inside the compiler. The compiler should just emit >> >> these annotations into dwarf. Currently in the linux build system, >> >> pahole will convert dwarf to BTF which will encode these annotation >> >> strings into BTF. The following is a C example how annotations look >> >> like at source level: >> >> >> >> $ cat t1.c >> >> /* a pointer pointing to user memory */ >> >> #define __user __attribute__((annotate("user"))) >> >> /* a pointer protected by rcu */ >> >> #define __rcu __attribute__((annotate("rcu"))) >> >> /* the struct has some special property */ >> >> #define __special_struct __attribute__((annotate("special_struct"))) >> >> /* sock_lock is held for the function */ >> >> #define __sock_lock_held __attribute((annotate("sock_lock_held"))) >> >> /* the hash table element type is socket */ >> >> #define __special_info __attribute__((annotate("elem_type:socket"))) >> >> >> >> struct hlist_node; >> >> struct hlist_head { >> >> struct hlist_node *prev; >> >> struct hlist_node *next; >> >> } __special_struct; >> >> struct hlist { >> >> struct hlist_head head __special_info; >> >> }; >> >> >> >> extern void bar(struct hlist *); >> >> int foo(struct hlist *h, int *a __user, int *b __rcu) __sock_lock_held { >> >> bar(h); >> >> return *a + *b; >> >> } >> >> >> >> In https://reviews.llvm.org/D103667, I implemented a LLVM extended attribute >> >> DWARF_AT_LLVM_annotations. But this might not be the right thing to do >> >> as it is not clear whether there are use cases beyond BPF. >> >> David suggested that we discuss this in llvm-dev to get consensus on >> >> how this feature may be supported in LLVM. Hence this email. >> >> >> >> Please share your comments, suggestions on how to support this feature >> >> in LLVM. Thanks! >> >> >> >> Yonghong