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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@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"üüü".

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.





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux