bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	"Jose E. Marchesi" <jose.marchesi@oracle.com>,
	Yonghong Song <yonghong.song@linux.dev>
Cc: Alan Maguire <alan.maguire@oracle.com>,
	dwarves <dwarves@vger.kernel.org>,  bpf <bpf@vger.kernel.org>
Subject: Re: [RFC dwarves 5/6] btf_encoder: Do not error out if BTF is not found in some input files
Date: Thu, 07 Aug 2025 12:18:35 -0700	[thread overview]
Message-ID: <1c78d157e7f174fd3eb154bf0655f0d14650b43e.camel@gmail.com> (raw)
In-Reply-To: <CAADnVQ+x3Jir0s=nsvw7eV54FJjFkfwx=+xWMM4bFHHmwD5ORw@mail.gmail.com>

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

  reply	other threads:[~2025-08-07 19:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-07 14:42 [RFC dwarves 0/6] prep for compiler-generated BTF Alan Maguire
2025-08-07 14:42 ` [RFC dwarves 1/6] btf_loader: Make BTF representation match DWARF Alan Maguire
2025-08-07 14:42 ` [RFC dwarves 2/6] pfunct: Fix up function display with updated prototype representation Alan Maguire
2025-08-07 14:42 ` [RFC dwarves 3/6] pahole: Add btf_encode to conf_load Alan Maguire
2025-08-07 14:42 ` [RFC dwarves 4/6] btf_loader: read ELF for BTF encoding Alan Maguire
2025-08-07 14:42 ` [RFC dwarves 5/6] btf_encoder: Do not error out if BTF is not found in some input files Alan Maguire
2025-08-07 15:59   ` Alexei Starovoitov
2025-08-07 16:36     ` Jose E. Marchesi
2025-08-07 17:12       ` Alexei Starovoitov
2025-08-07 19:18         ` Eduard Zingerman [this message]
2025-08-08  5:39           ` Yonghong Song
2025-08-07 14:42 ` [RFC dwarves 6/6] tests: Add test of pahole using BTF as input to BTF generation Alan Maguire

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1c78d157e7f174fd3eb154bf0655f0d14650b43e.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=alan.maguire@oracle.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=dwarves@vger.kernel.org \
    --cc=jose.marchesi@oracle.com \
    --cc=yonghong.song@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).