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

[Y Song via llvm-dev]

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