On Fri, Dec 17, 2021 at 11:40:10AM +0100, Jose E. Marchesi wrote:
>
> 2) The need for DWARF to convey free-text tags on certain elements, such
> as members of struct types.
>
> The motivation for this was originally the way the Linux kernel
> generates its BTF information, using pahole, using DWARF as a source.
> As we discussed in our last exchange on this topic, this is
> accidental, i.e. if the kernel switched to generate BTF directly from
> the compiler and the linker could merge/deduplicate BTF, there would
> be no need for using DWARF to act as the "unwilling conveyer" of this
> information. There are additional benefits of this second approach.
> Thats why we didn't plan to add these extended DWARF DIEs to GCC.
>
> However, it now seems that a DWARF consumer, the drgn project, would
> also benefit from having such a support in DWARF to distinguish
> between different kind of pointers.
drgn can use .percpu section in vmlinux for global percpu vars.
For pointers the annotation is indeed necessary.
> So it seems to me that now we have two use-cases for adding support
> for these free-text tags to DWARF, as a proper extension to the
> format, strictly unrelated to BTF, BPF or even the kernel, since:
> - This is not kernel specific.
> - This is not directly related to BTF.
> - This is not directly related to BPF.
__percpu annotation is kernel specific.
__user and __rcu are kernel specific too.
Only BPF and BTF can meaningfully consume all three.
drgn can consume __percpu.
In that sense if GCC follows LLVM and emits compiler specific DWARF tag
pahole can convert it to the same BTF regardless whether kernel
was compiled with clang or gcc.
drgn can consume dwarf generated by clang or gcc as well even when BTF
is not there. That is the fastest way forward.
In that sense it would be nice to have common DWARF tag for pointer
annotations, but it's not mandatory. The time is the most valuable asset.
Implementing GCC specific DWARF tag doesn't require committee voting
and the mailing list bikeshedding.
> 3) Addition of C-family language-level constructions to specify
> free-text tags on certain language elements, such as struct fields.
>
> These are the attributes, or built-ins or whatever syntax.
>
> Note that, strictly speaking:
> - This is orthogonal to both DWARF and BTF, and any other supported
> debugging format, which may or may not be expressive enough to
> convey the free-form text tag.
> - This is not specific to BPF.
>
> Therefore I would avoid any reference to BTF or BPF in the attribute
> names. Something like `__attribute__((btf_tag("arbitrary_str")))'
> makes very little sense to me; the attribute name ought to be more
> generic.
Let's agree to disagree.
When BPF ISA was designed we didn't go to Intel, Arm, Mips, etc in order to
come up with the best ISA that would JIT to those architectures the best
possible way. Same thing with btf_tag. Today it is specific to BTF and BPF
only. Hence it's called this way. Whenever actual users will appear that need
free-text tags on a struct field then and only then will be the time to discuss
generic tag name. Just because "free-text tag on a struct field" sounds generic
it doesn't mean that it has any use case beyond what we're using it for in BPF
land. It goes back to the point of coding now instead of talking about coding.
If gcc wants to call it __attribute__((my_precious_gcc_tag("arbitrary_str")))
go ahead and code it this way. The include/linux/compiler.h can accommodate it.
