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

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

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>