Hello. > I'm trying to use Gentoo's bpf-toolchain - basically just gcc built for > the BPF target - to build the CO-RE support in bpftool, in order to > provide an alternative to clang. > > This currently fails because the feature detection relies on a comment > in the generated BPF assembly, which gcc does not seem to generate. > > While I'm using the Github mirror for bpftool, the same check is > being done in the kernel build, so it affects both. > > Our tracker bug with full output etc. is: https://bugs.gentoo.org/943113 > > Basically the problem boils down to: > > .long 16777248 # 0x1000020 > .long 9 # BTF_KIND_VAR(id = 3) > .long 234881024 # 0xe000000 > > generated by clang (19.1.3) > > vs. > > .4byte 0x1000020 > .4byte 0x9 > .4byte 0xe000000 > > generated by gcc (14.2.0). > > As the values themselves are correct, the problem is really just > the missing debug information in gcc's output. So far I've tried > every option I could find, but to no avail. I have no idea whether > this is because I'm holding it wrong, gcc cannot do it for the bpf > target (yet?) or anything else. > > Does anybody know how I can convince gcc to generate symbol comments? > Alternatively can we find a better way to verify the generated output > instead of grepping for a comment? GCC can generate similar comments if you pass the -dA option. These are intended for testing the generated BTF in the GCC testsuite, however, and right now I don't remember whether the comments mimic what clang generates. You can give it a try... > > This is not really a bug, but IMHO having an alternative toolchain to > build BPF seems like a good idea in general. Gentoo's bpf-toolchain > package was initially made to build dtrace, and seems to be working > fine so far. > > Thanks for any suggestions! > > cheers > Holger
