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

[Alexei Starovoitov via llvm-dev]

On Thu, Jun 10, 2021 at 12:42 PM David Blaikie <dblaikie at gmail.com> wrote:
>
>> >
>> >
>> > Any suggestions/preferences for the spelling, Aaron?
>>
>> I don't know this domain particularly well, so takes these suggestions
>> with a giant grain of salt:
>>
>> If the concept is specific to DWARF and you don't think it'll need to
>> extend into other debug formats, you could go with `dwarf_annotate`.
>> If it's not really a DWARF thing but is more about B[P|T]F, then
>> `btf_annotate`  or `bpf_annotate` could work, but those may be a bit
>> mysterious to folks outside of the domain. If it's a generic debug
>> info concept, probably `debug_info_annotate` or something.
>
>
> Arguably it can/could be a generic debug info or dwarf thing, but for now we don't have any use for it other than to squirrel info along to BTF/BPF so I'm on the fence about which prefix to use exactly
>

A bit more bike shedding colors...

The __rcu and __user annations might be used by the clang itself eventually.
Currently the "sparse" tool is doing this analysis and warns users
when __rcu pointer is incorrectly accessed in the kernel C code.
If clang can do that directly that could be a huge selling point
for folks to switch from gcc to clang for kernel builds.
The front-end would treat such annotations as arbitrary string, but
special "building-linux-kernel-pass" would interpret the semantical context.

Considering above the dwarf_annotate, btf_annotate, debug_info_annotate
names don't fit that well. The accuracy of the annotations is important
unlike debug info that can be dropped on a whim of some optimization pass.

bpf_annotate wouldn't fit either, since the kernel might use that
without any bpf bits.

kernel_annotate might sound like it's not applicable to user space.

How about __attribute__((note("str"))) or __attribute__((tag("str"))) ?