[PATCH] D143967: [DebugInfo][BPF] Add 'btf:type_tag' annotation in DWARF

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a subscriber: aprantl.
dblaikie added a comment.

In D143967#4441333 <https://reviews.llvm.org/D143967#4441333>, @eddyz87 wrote:

> In D143967#4438815 <https://reviews.llvm.org/D143967#4438815>, @dblaikie wrote:
>
>> I haven't looked closely at this, but from a vague/quick reading, it sounds like this is creating annotations on certain type DINodes, but then moving them around to different types? It'd be nice if we could avoid that/create them in the right place in the first place.
>
> Hi @dblaikie, thank you for taking a look!
>
> I assume you refer to the "placeholder" nodes created for annotated types.
> ...

Yeah, seems unfortunate to break the abstractions and have to add members and finalizing for such a narrow feature too. Though I appreciate the complications with adding this during type building too.

So you get some bunch of annotations from the `BTFTagAttributedType`, then you build the underlying type (which might already be built/needed/fine because it's used without attributes in other places/needs to exist independently) - and then at the end you copy any of these types that are needed and put the annotations on them? Does the `BTFTagAttributedType` always have to apply to the immediate type that's going to be modified/mutated to have the attributes applied to it directly? Is the set of types that may have these attributes/annotations added small/closed? (struct types, void, anything else? could you add tags to `int __tag *`, for instance and get a `DW_TAG_base_type` for "int" with annotations on it?

If it's really generic/can apply to any type - but always the /immediate/ type (I guess with the special handling you've got to skip applying it to the `DW_TAG_const_type`, etc)...

What if you skipped `getOrCreateType` - and called into the `CreateType` dispatch below that? Since you never want a cached instance of a type, right? You want to create a new copy of the type you could then apply annotations to.

Except, I guess, in the instance you showed, where the type is being completed - can't go and create another one, because we're part-way through building this one... hmm, maybe you can, though? What happens if we start making a totally distinct copy of that same type? I guess there's some map that contains such partially completed types, and that map would get confused/break if we tried to build two types for the same type without adding in some extra key goo that contained the annotations... - maybe that wouldn't be too invasive, though?

Hmm - I guess what to put in the type cache would be an interesting question. Though that does raise other questions.

given this code:

  #define __tag1 __attribute__((btf_type_tag("tag1")))
  
  struct st {
    struct st *self;
  };
  struct st __tag1 x;

What's the expected DWARF here? `x`'s type is a the attributed/annotated `st` type, but then does the `self` pointer inside there point to the attributed type or the unattributed type?

Maybe what you've got is the best of some bad options, but I'm not sure/trying to think it through. (@aprantl wouldn't mind your perspective - if it's too much to consume easily, let me know and I can make a best-effort at summarizing, maybe even better over a video chat if you've got a few minutes)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D143967/new/

https://reviews.llvm.org/D143967