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

[Y Song via llvm-dev]

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.

>
> 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.

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