[cfe-dev] [llvm-dev] put "str" in __attribute__((annotate("str"))) to dwarf

[David Blaikie via cfe-dev]

(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?

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 <aaron at aaronballman.com> thoughts on this?


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/cfe-dev/attachments/20210610/d78484e3/attachment.html>