[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