> On Thu, Aug 7, 2025 at 7:42 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: >> >> This is no substitute for link-time BTF deduplication of course, but >> it does provide a simple way to see the BTF that gcc generates for vmlinux. >> >> The idea is that we can explore differences in BTF generation across >> the various combinations >> >> 1. debug info source: DWARF; dedup done via pahole (traditional) >> 2. debug info source: compiler-generated BTF; dedup done via pahole (above) >> 3. debug info source: compiler-generated BTF; dedup done via linker (TBD) >> >> Handling 3 - linker-based dedup - will require BTF archives so that is the >> next step we need to explore. > > Overall, the patch set makes sense and we need to make this step in pahole, > but before we start any discussion about 3 and BTF archives > the 1 and 2 above need to reach parity. > Not just being close enough, but an exact equivalence. > > But, frankly, gcc support for btf_decl_tags is much much higher priority > than any of this. > > We're tired of adding hacks through the bpf subsystem, because > gcc cannot do decl_tags. > Here are the hacks that will be removed: > 1. BTF_TYPE_SAFE* > 2. raw_tp_null_args[] > 3. KF_ARENA_ARG > and probably other cases. We are getting there. The C front-end maintainer just looked at the latest version of the series [1] and, other than a small observation concerning wide char strings, he seems to be ok with the attributes. [1] https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692057.html
