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

[Alexei Starovoitov via llvm-dev]

On Fri, Jun 11, 2021 at 07:17:32AM -0400, Aaron Ballman wrote:
> On Thu, Jun 10, 2021 at 8:47 PM Alexei Starovoitov
> <alexei.starovoitov at gmail.com> wrote:
> >
> > 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.
> 
> Are __rcu and __user annotations notionally distinct things from bpf
> (and perhaps each other as well)? Distinct enough that it would make
> sense to use a different attribute name for user source for each need?
> I suspect the answer is yes given that the existing annotations have
> their own names which are distinct, but I don't know this domain
> enough to be sure.

__rcu and __user don't overlap. __rcu is not a single annotation though.
It's a combination of annotations in pointers, functions, macros.
Some functions have:
__acquires(rcu)
another function might have:
__acquires(rcu_bh)
There are several flavors of the RCU in the kernel.
So single __attribute__((rcu_annotate("foo"))) won't work even within RCU scope.
But if we do:
struct foo {
  void * __attribute__((tag("ptr.rcu_bh")) ptr;
};
int bar(int) __attribute__((tag("acquires.rcu_bh")) { ... }
int baz(int) __attribute__((tag("releases.rcu_bh")) { ... }
int qux(int) __attribute__((tag("acquires.rcu_sched")) { ... }
...
The clang pass can parse these strings and correlate one tag to another.
RCU flavors come and go, so clang cannot hard code the names.