On Thu, Aug 7, 2025 at 9:37 AM Jose E. Marchesi <jose.marchesi@xxxxxxxxxx> wrote: > > > > 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 Good to know. Yonghong, what does llvm do with wchar?
