Re: [RFC dwarves 5/6] btf_encoder: Do not error out if BTF is not found in some input files

[Yonghong Song <yonghong.song@linux.dev>]

On 8/7/25 12:18 PM, Eduard Zingerman wrote:
> 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@oracle.com> wrote:
>>>
>>>> On Thu, Aug 7, 2025 at 7:42 AM Alan Maguire <alan.maguire@oracle.com> 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"üüü".

If we remove 'u8' prefix, there will be no warnings. For example,

$ cat wide-string-test.c
__attribute__((btf_decl_tag("üüü")))
int foo(void) { return 42; }
$ clang --target=bpf -O2 -g wide-string-test.c -c -o wide-string-test.o
$

"üüü" will be treated similar to other ascii strings w.r.t. decl/type tag.