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

Eduard Zingerman via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Mar 15 11:14:28 PDT 2023


eddyz87 added a comment.

> ! In D143967#4197142 <https://reviews.llvm.org/D143967#4197142>, @jemarch wrote:
>  ...
>  In GCC we also translate from the internal DWARF structures into BTF.
>  So, for us, it would also imply to reoder (before generating the BTF
>  from the interal DWARF) in case we wanted to use a different approach in
>  DWARF than in BTF.

It's not only the BTF generated for BPF programs. There are two ways
to obtain BTF that we should worry about:

1. BTF generated for BPF programs by compiler;
2. BTF generated during kernel build for the whole kernel, this one is generated by `pahole` from DWARF.

> I think the question is: what are the consequences of having the
> annotation DIE as a child of the qualifiers instead of the qualified
> type?

Are there any? I just tried the following code with GDB:

  volatile int __attribute__((btf_type_tag("__a"))) a = 1;
  
  void foo(void) {
    a = 2;
  }
  
  int main(int argc, char **argv) {
    foo();
    return 0;
  }

No warnings, `a` can be inspected.

I think there are two sides to this:

- conceptual: is it ok to allow annotations for CVR modifiers?
- technical: what is the point where such reordering is easiest to implement? For LLVM / pahole stack the path of least resistance is to modify DWARF generation (but again @dblaikie might disagree). How hard is it to adjust DI generation in GCC in this way?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143967



More information about the llvm-commits mailing list