On Mon, Feb 27, 2023 at 9:28 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Mon, Feb 27, 2023 at 6:44 PM Alexei Starovoitov
> <alexei.starovoitov@xxxxxxxxx> wrote:
> >
> > On Mon, Feb 27, 2023 at 4:57 PM Eduard Zingerman <eddyz87@xxxxxxxxx> wrote:
> > >
> > > I still think that presence of a literal string "bty_type_tag" might
> > > make some grepping easier but whatever. If there are no further
> > > objections I'll post the changes using "btf:type_tag" literal tomorrow.
> > > Andrii, thanks for the input.
> >
> > I don't think there is precedent for using ':' inside DW_AT_name.
>
> I don't think there are any restrictions on string pointed to be
> DW_AT_name. It is used when describing source code location (so
> definitely has '/' on Linux, and ":/" on Windows). But I just checked
> Rust-emitted DWARF:
>
> 0x0002825e: DW_TAG_pointer_type
> DW_AT_type (0x00026fc9
> "core::option::Option<alloc::string::String>")
> DW_AT_name ("*const
> core::option::Option<alloc::string::String>")
> DW_AT_address_class (0x00000000)
>
> So I'm not too bothered about this. After all, it's just a string.
>
> But `btf:<something>` allows us to generalize this to other
> annotations, e.g., we can have "msan:initialized" or something, and it
> will be done in C using some generic __attribute__((annotate("msan",
> "initialized"))).
>
> > Can we actually use the same "btf_type_tag" name?
> > Aren't we gonna use a different container than DW_TAG_LLVM_annotation ?
>
> I think that was the point to reuse existing DW_TAG_LLVM_annotation
> (and I assume from GCC's side it would be called
> DW_TAG_GNU_annotation, but it will use the same ID, so effectively we
> might as well call it just DW_TAG_annotation), so using "btf_type_tag"
> becomes ambiguous.
I see. Then 'btf:type_tag' makes the most sense.
