On Thu, 2025-08-07 at 10:12 -0700, Alexei Starovoitov wrote: > 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? The literal is copied as-is with a warning. $ cat wide-string-test.c __attribute__((btf_decl_tag(u8"üüü"))) int foo(void) { return 42; } $ clang --target=bpf -O2 -g wide-string-test.c -c -o wide-string-test.o wide-string-test.c:1:29: warning: encoding prefix 'u8' on an unevaluated string literal has no effect [-Winvalid-unevaluated-string] 1 | __attribute__((btf_decl_tag(u8"üüü"))) | ^~ 1 warning generated. $ bpftool btf dump file wide-string-test.o [1] FUNC_PROTO '(anon)' ret_type_id=2 vlen=0 [2] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED [3] FUNC 'foo' type_id=1 linkage=global [4] DECL_TAG 'üüü' type_id=3 component_idx=-1 "As-is" means using compiler internal encoding (UTF8), e.g. above u8"üüü" is encoded as "c3 bc c3 bc c3 bc" in the final .BTF section, same happens for UTF32 literal U"üüü".