[PATCH] D103667: [WIP] BPF: add support for DWARF_AT_LLVM_annotations attribute

Thu Jun 3 23:57:20 PDT 2021

yonghong-song added a comment.

In D103667#2798165 <https://reviews.llvm.org/D103667#2798165>, @dblaikie wrote:

> Is the C source syntax already fixed? Could it use a more specific name - then maybe wouldn't need the flag to opt-in if the only places the attribute appears is where it should be propagated?

No. C source syntax is not fixed. The idea is to pass attributes to functions/variables/structures/fields to dwarf. We can discuss what is the best way to achieve this. Definitely we can change dwarf attribute name
or even the attribute name. If we only focus on BPF use cases (C only), yes, we really only have a few places and opt-in should be fine as I don't think a lot of people use annotate attributes.

> This'll end up being broken down into many smaller patches (IR+LangRef+Bitcode support for each attribute separately, ideally, I think, for instance - separate patches for frontend generation and backend use in DWARF emission).

Thanks. This patch is a mix trying to show what the end result could be. Once we agreed on syntax and scope of the attribute, I can break it into multiple patches.

> Probably worth an llvm-dev thread with the usual suspects (@probinson @aprantl @JDevlieghere and myself at least) - laying out the IR changes and DWARF changes (the name of the new attribute, the DIEs it'll appear on).

Yes, it is a good idea to discuss on llvm-dev instead here to hash out design issues. Will post in the next few days.

> One thing that might be worth hashing out is whether this is DW_AT_LLVM or DW_AT_BTF (or BPF, not sure which one applies here) - whether it should be general for other uses. Given how opaque it is, I'm sort of hesitant to suggest it has a really general use - then it gets really fuzzy who's using it for what, what format it has, how to interpret it, etc. So I'd sort of be inclined towards naming it something BPF-specific, for instance.

That is all good points. Agreed that we don't want to generalize it for the sake of just generalization. I am okay either way. We can discuss more llvm-dev mailing list.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103667