llvm dev - Jun 2021 - put "str" in __attribute__((annotate("str"))) to dwarf

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

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