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.
>
> Since we're picking a standard across gcc and llvm it will be
> some common DW_TAG_... with the same number, no ?
> I forgot what we agreed on during office hours.
