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

[Y Song via llvm-dev]

On Thu, Jun 17, 2021 at 3:48 PM <paul.robinson at sony.com> wrote:
>
> > > Maybe this is a good opportunity to design a generic mechanism that
> > works for all attributes? We probably need to add a little more structure
> > than just encoding a single string with the attribute contents to make the
> > encoding more efficient, but we could probably have something generic
> > enough to be useful across many use-cases.
> > >
> > > Is there any interest in attempting this or do you prefer with targeted
> > extensions for each kind of attribute?
> >
> > David,
> >
> > What is your opinion on this? Even if we want to emit all clang
> > __attribute__(())'s as a string to dwarf, I think
> > bpf_tag(()) is still needed since it is an attribute to introduce bpf
> > tag strings.
> >
> > But encoding in IR/bitcode/dwarf probably needs more discussion and
> > possibly we may need to introduce strlist form
> > in dwarf so different attributes won't mix with each other. The
> > IR/bitcode representation will be a challenge and the
> > value might need to be a vector of strings.
> >
> > Also, by default, I think we should encode bpf_tag() attributes into
> > dwarf since bpf_tag() is designed to be passed
> > to dwarf. For all other attributes, we may want to have a frontend
> > flag to control whether to put their attribute strings
> > in dwarf or not.
> >
> > Just my 2cents.
>
> DWARF has no FORMs with multiple values, and I can't see the
> committee being willing to accept such a FORM.  DWARF's mechanism
> for doing lists is to put elements in their own DIEs, as children
> under the related parent DIE, and then you repeat them as needed.
> For example, multiple annotations with different kinds of values
> could be done fairly easily this way:
>
> DW_TAG_variable
>    DW_AT_name "variable_with_annotations"
>
>    DW_TAG_LLVM_annotation
>       DW_AT_name "annotation_name1"
>       DW_AT_const_value "annotation_string_value"
>
>    DW_TAG_LLVM_annotation
>       DW_AT_name "annotation_name2"
>       DW_AT_const_value 23
>
> All you need (DWARF-wise) is to define the one new tag, and
> all the rest is existing standard DWARFish ways of operating.
> DW_AT_name is the natural way to provide a string name for
> something, and DW_AT_const_value is the most flexible way to
> attach an arbitrary compile-time value as a parameter.

Thanks for your suggestions. This is indeed very flexible
and extensible and can cover arbitrary attributes including
proposed "bpf_tag". With this mechanism, we do not
need to merge "bpf_tag" strings.

At IR level, we can add things like
   ..., annotations: !10 ...
!10 = !{!11, !12}
!11 = !{!"annotation_name1", !value1}
!12 = !{!"annotation_name2", !value2}
...

>
> (I'm actually on holiday and haven't looked at whether it seems

Thanks for your reply!

> that DWARF is an optimal place to put these things; but given
> that DWARF is the right place, the above is how I would go about
> adding the annotations.)
> (Also haven't thought about whether a separate BPF-specific tag
> would be preferable; it might be.)
>
> --paulr
>
>