On Mon, Apr 28, 2025 at 8:21 AM Alan Maguire <alan.maguire@xxxxxxxxxx> wrote: > > <1><4bd05>: Abbrev Number: 58 (DW_TAG_pointer_type) > <4bd06> DW_AT_byte_size : 8 > <4bd07> DW_AT_address_class: 2 > <4bd08> DW_AT_type : <0x301cd> > > ...which points at an int > > <1><301cd>: Abbrev Number: 214 (DW_TAG_base_type) > <301cf> DW_AT_byte_size : 4 > <301d0> DW_AT_encoding : 5 (signed) > <301d1> DW_AT_name : int > <301d5> DW_AT_name : int > > ...but note the the DW_AT_address_class attribute in the latter case and > the two DW_AT_name values. We don't use that address attribute in pahole > as far as I can see, but it might be enough to cause problems. DW_AT_address_class is there because it's an actual address space qualifier in C. The dwarf is correct, but I thought pahole will ignore it while converting to BTF, so it shouldn't matter from dedup pov. And since dedup is working for vmlinux BTF, I doubt there are CUs where the same type is represented with different dwarf id-s. Otherwise dedup wouldn't have worked for vmlinux. DW_AT_name is concerning. Sounds like it's a gcc bug, but it shouldn't be causing dedup issues for modules. So what is the workaround? We need to find it asap. Since at present we cannot build kernels with gcc-14, since modules won't dedup BTF. Hence a bunch of selftests/bpf are failing. We want to upgrade BPF CI to gcc-14 to catch nginx-like issues, but we cannot until this pahole/dedup issue is resolved.
