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

[David Blaikie via llvm-dev]

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>