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

[via llvm-dev]

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

(I'm actually on holiday and haven't looked at whether it seems
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